perm filename CLOOPS.MSG[COM,LSP]10 blob
sn#859603 filedate 1988-07-18 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00002 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002
C00003 ENDMK
C⊗;
∂16-May-88 1139 Common-Lisp-Object-System-mailer CLOS document numbers for June meeting
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 16 May 88 11:37:59 PDT
Received: by labrea.stanford.edu; Mon, 16 May 88 11:37:44 PDT
Received: from sunvalleymall.lucid.com by edsel id AA25773g; Mon, 16 May 88 11:13:24 PDT
Received: by sunvalleymall id AA28381g; Mon, 16 May 88 11:16:26 PDT
Date: Mon, 16 May 88 11:16:26 PDT
From: Jan Zubkoff <edsel!jlz@labrea.stanford.edu>
Message-Id: <8805161816.AA28381@sunvalleymall.lucid.com>
To: common-lisp-object-system@sail.stanford.edu
Subject: CLOS document numbers for June meeting
CLOS chapters 1&2: 88-002R
CLOS chapters 3: 88-003R
∂16-May-88 1524 Common-Lisp-Object-System-mailer Chapter 2
To: common-lisp-object-system@SAIL.Stanford.EDU
From: Linda DeMichiel <LGD@SAIL.Stanford.EDU>
New Chapter 2 files are now available as functi.*[cls,lsp] on sail.
This material should now be up-to-date except for whatever we decide
to do with check-keyword-arguments.
Please send comments and corrections to me by Thursday morning.
-lgd
∂17-May-88 1340 Common-Lisp-Object-System-mailer Re: check-keyword-arguments
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 May 88 13:40:43 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 MAY 88 13:38:44 PDT
Date: 17 May 88 13:38 PDT
Sender: Bobrow.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Subject: Re: check-keyword-arguments
In-reply-to: Dick Gabriel <RPG@SAIL.Stanford.EDU>'s message of 15 May 88 13:56
PDT
To: RPG@SAIL.Stanford.EDU
cc: common-lisp-object-system@SAIL.Stanford.EDU
Message-ID: <880517-133844-2742@Xerox>
I have no worries that someone who is writing his own version
of make-instance could look in chapter 3 or 4 to find out how to do
error checking. Therefore, only a check-keyword-arguments that is
more generally useful justifies going beyond specifying a
procedural definition of make-instance that is reasonable only for
correct invocations of it.
I am now satisfied that your more general version of check-keyword-arguments can
be useful. It would be good to have this last issue for chapter 2
(check-keyword-arguments) settled, and am happy to have it as last specified.
∂18-May-88 1101 Common-Lisp-Object-System-mailer
Received: from ti.com by SAIL.Stanford.EDU with TCP; 18 May 88 11:01:24 PDT
Received: by ti.com id AA20889; Wed, 18 May 88 07:13:51 CDT
Received: from Jenner by tilde id AA06761; Wed, 18 May 88 07:12:44 CDT
Message-Id: <2788949394-1458237@Jenner>
Date: Wed, 18 May 88 07:09:54 CDT
From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
To: common-lisp-object-system@SAIL.STANFORD.EDU
Subject: Re: check-keyword-arguments
In-Reply-To: Msg of 17 May 88 13:38 PDT from Danny Bobrow <Bobrow.pa@XEROX.COM>
I am now satisfied that your more general version of check-keyword-arguments can
be useful. It would be good to have this last issue for chapter 2
(check-keyword-arguments) settled, and am happy to have it as last specified.
I agree.
Patrick.
∂18-May-88 1818 Common-Lisp-Object-System-mailer Comments on new draft chapter 1 (dated May 13 20:53)
Received: from AI.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 May 88 18:18:27 PDT
Date: Wed, 18 May 88 21:22:40 EDT
From: "David A. Moon" <MOON@AI.AI.MIT.EDU>
Subject: Comments on new draft chapter 1 (dated May 13 20:53)
To: Common-lisp-object-system@SAIL.STANFORD.EDU
Message-ID: <380679.880518.MOON@AI.AI.MIT.EDU>
1-12 fourth bullet: typos "an :documentation", "documentation documentation"
1-30 first bullet, also second dash bullet: These say an error is
signalled if call-next-method is called when there is no next method.
I thought we changed that to call a generic function whose name escapes
me at the moment, whose default method signals an error.
1-31 last bullet: ditto
1-35: Should the four simple mechanisms listed be augmented with
shared-initialize as a fifth bullet?
1-38 4th paragraph: maybe this should be "initialize-instance or
shared-initialize methods should be used instead."
1-39 penultimate paragraph: shared-initialize does not take three
arguments, it takes two required arguments plus a set of &key arguments.
The initialization arguments are passed as separate arguments, not as a list.
1-40 first paragraph after first three bullets: should be "whose first
parameter specializer is the class standard-object".
1-41 1st paragraph: same comment as 1-39.
1-41 last line: the parameter name is instance, not class, and the
parameter specializer is standard-object, not standard-class.
1-43 4th paragraph: There is a stray sentence fragment "the value
of the shared slot in the old class."
1-43 6th paragraph: I think this should mention that the process can
also be triggered by an explicit call to the function make-instances-obsolete.
1-44 6th paragraph: Rather than saying update-instance-for-redefined-class
takes an &rest argument which is a list of initialization arguments, I
believe it is more correct terminology to say that it takes &key arguments
which are the initialization arguments. The default method may receive these
with an &rest parameter, but the generic function's lambda-list says &key,
not &rest.
1-44 last paragraph: same comment as 1-39.
1-46 penultimate paragraph: same comment as 1-44 6th.
1-47 last paragraph: same comment as 1-39.
1-48 3rd paragraph: same comment as 1-44 6th.
1-48 last paragraph: same comment as 1-39.
∂18-May-88 2007 Common-Lisp-Object-System-mailer Comments on new draft chapter 2 (dated May 16 15:09)
Received: from AI.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 May 88 20:06:58 PDT
Date: Wed, 18 May 88 23:11:11 EDT
From: "David A. Moon" <MOON@AI.AI.MIT.EDU>
Subject: Comments on new draft chapter 2 (dated May 16 15:09)
To: Common-lisp-object-system@SAIL.STANFORD.EDU
Message-ID: <380731.880518.MOON@AI.AI.MIT.EDU>
There is also one comment on chapter 1 in here.
2-6 first paragraph: I'm not sure what is meant by behavior intrinsic to a
generic function itself. I think this probably means a contract that all
methods must obey (as distinguished from idiosyncratic behavior of one
particular method).
2-12: This says call-next-method signals an error, but I thought we
changed it to call a generic function whose default method signals an error.
2-15: In the defmethod, change "&rest initargs" to "&key" for better style,
since this method doesn't use or define any initargs, it should have an
empty set of &key parameters. Also this method should be a :before method;
not a :after method, because we want to initialize the slots ourselves,
not let the primary method initialize them from initforms then reinitialize
them ourselves. I think 1-44 and 1-47 should be modified to reflect this
valid use of :before methods for the two update- functions; they differ
in this respect from initialize-instance and reinitialize-instance.
2-17: The method signatures imply that only standard classes have names,
but I believe the intent was that all classes have names. Certainly
built-in and structure classes do have names.
2-21 3rd paragraph: Someone complained that "The slot-name argument is
a symbol that can be used as a Common Lisp variable name." was ambiguous.
What we mean is that the symbol is syntactically valid for use as a
variable name, what we don't mean is that referencing a variable with
this name will access the slot. This should be rephrased if possible.
2-33 last paragraph: The value returned by define-method-combination
should be the method combination meta object (now that we have them),
not the name.
2-37 2nd paragraph: I don't understand what this paragraph is doing
here. Keyword options to what? Did this paragraph drift in from
somewhere earlier in the define-method-combination section perhaps?
2-43: There is documentation for slot descriptor objects now too.
Since only chapter 3 describes those, I don't know whether slot
documentation should be documented in the normal way, or just
mentioned as a remark. I think I prefer the former.
2-45 4th paragraph: Because of the way rule 4 for lambda-list
congruence is defined, I think this has to speak not of the old
and new lambda-lists for the generic function being congruent,
but of the new lambda-list for the generic function being congruent
with the lambda-lists of all existing methods. If an implementation
can sometimes optimize this into a comparison with the old lambda
list for the generic function, that's merely an optimization.
2-55 2nd paragraph: I don't think the system supplied primary
method for initialize-instance checks the validity of the arguments,
since chapter 1 says make-instance takes care of that. Unlike
reinitialize-instance, initialize-instance is not meant to be
called by the user.
2-55 Remarks field: This is not really accurate, as the generic
functions for which methods can be defined varies. Chapter 1
describes this better, maybe the description should not be
repeated here. It would be useful to have a remark that the programmer
is intended to define :after methods for initialize-instance.
2-58: Formatting of method signatures is particularly ugly here.
How about right-justifying "[Primary Method]" throughout this chapter?
2-74,5,6: Are you sure slot-boundp, slot-exists-p, and slot-makunbound
are generic? slot-value isn't. I guess Gregor has final say on this point.
2-85: Same comments as for 2-15.
2-90 first remarks paragraph: same comment as for 2-45.
2-92: with-slots should cross-reference with-accessors
∂19-May-88 1613 Common-Lisp-Object-System-mailer check-keyword-arguments
To: common-lisp-object-system@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I want to present one more alternative to the initargs checking
problem. This alternative was the result of a couple of hours'
discussion with Guy Steele tuesday night. There are two parts to
it. One is the real technical proposal, and the remainder is the
packaging for chapter 1.
We could introduce a new generic function called valid-keywords, which
takes an object; if it is something with keywords (like a generic
function, a method, or a function), valid-keywords returns two values: a
list of the explicitly named keywords and a boolean which states whether
&allow-other-keys had been specified in the definition.
Then we could write make-instance like this:
(defmethod make-instance ((class standard-class) &rest initargs)
(setq initargs (default-initargs class initargs))
(let* ((proto (class-prototype class))
(methods
(union
(compute-applicable-methods #'allocate-instance `(,class))
(union
(compute-applicable-methods #'initialize-instance `(,proto nil))
(compute-applicable-methods #'shared-initialize `(,proto))))))
(unless
(subsetp
(let ((keys '()))
(do ((plist initargs (cddr plist)))
((null plist) keys)
(push (car plist) keys)))
(union
(class-slot-initargs class)
(reduce #'union (mapcar #'valid-keywords methods))))
(error ...)))
(let ((instance (apply #'allocate-instance class initargs)))
(apply #'initialize-instance instance initargs)
instance))
Or something like this: the details of the code are not important
for chapters 1 and 2.
This is not a very simple piece of code to present in chapter 1. So
the proposal requires a sample of how to explain this:
\beginsubSection{Definitions of Make-Instance and Initialize-Instance}
The generic function {\bf make-instance} behaves as if it were defined as
follows, except that certain optimizations are permitted:
\screen!
(defmethod make-instance ((class standard-class) &rest initargs)
(setq initargs (default-initargs class initargs))
...
(let ((instance (apply #'allocate-instance class initargs)))
(apply #'initialize-instance instance initargs)
instance))
(defmethod make-instance ((class-name symbol) &rest initargs)
(apply #'make-instance (find-class class-name) initargs))
\endscreen!
The elided code in the definition of {\bf make-instance} checks the
supplied initialization arguments to determine whether an initialization
argument was supplied that neither filled a slot nor supplied an argument
to an applicable method. This check could be implemented using the generic
functions {\bf class-prototype}, {\bf compute-applicable-methods}, {\bf
valid-keywords}, and {\bf class-slot-initargs}. See Chapter~3 for a
description of this initialization argument check.
The generic function {\bf initialize-instance} behaves as if it were
defined as follows, except that certain optimizations are permitted:
\screen!
(defmethod initialize-instance ((class standard-class) &rest initargs)
(apply #'shared-initialize instance t initargs)))
\endscreen!
These procedures can be customized at either the Programmer Interface level,
the meta-object level, or both.
Customizing at the Programmer Interface level includes using the {\bf
:initform}, {\bf :initarg}, and {\bf :default-initargs} options to
{\bf defclass}, as well as defining methods for {\bf make-instance}
and {\bf initialize-instance}. It is also possible to define
methods for {\bf shared-initialize}, which would be invoked by the
generic functions {\bf reinitialize-instance}, {\bf
update-instance-for-redefined-class}, {\bf
update-instance-for-different-class}, and {\bf
initialize-instance}. The meta-object level supports additional
customization by allowing methods to be defined on {\bf
make-instance}, {\bf default-initargs}, and {\bf
allocate-instance}. Chapters~2 and~3 document each of these generic
functions and the system-supplied primary methods.
Implementations are permitted to make certain optimizations to {\bf
initialize-instance} and {\bf shared-initialize}. The
description of {\bf shared-initialize} in Chapter~2 mentions the
possible optimizations.
Because of optimization, the check for valid initialization arguments
might not be implemented using the generic functions {\bf
class-prototype}, {\bf compute-applicable-methods}, {\bf valid-keywords},
and {\bf class-slot-initargs}. In addition, methods for the generic
function {\bf default-initargs}, and the system-supplied primary methods
for {\bf allocate-instance}, {\bf initialize-instance}, and {\bf
shared-initialize} may not be called on every call to {\bf make-instance}
or may not receive exactly the arguments that would be expected.
\endsubSection%{Definitions of MAKE-INSTANCE and Initialize-Instance}
∂20-May-88 1508 Common-Lisp-Object-System-mailer Comments on new draft chapter 1 (dated May 13 20:53)
Received: from XX.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 May 88 15:08:46 PDT
Received: from PERON.AI.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 20 May 88 17:32-EDT
Date: Fri, 20 May 88 17:35 EDT
From: Richard Mlynarik <MLY@AI.AI.MIT.EDU>
Subject: Comments on new draft chapter 1 (dated May 13 20:53)
To: common-lisp-object-system@sail.stanford.edu
Message-ID: <19880520213530.4.MLY@PERON.AI.MIT.EDU>
These comments come from someone who has been keeping an eye on the
cl-o-o-p mail, but hasn't been reading the specs regularly and closely.
I'm omitting remarks which would overlap those in
<380679.880518.MOON@AI.AI.MIT.EDU>
A general remark on all of the documents -- as a non-American and as
something of a pedant I feel my blood-pressure rising every time I
encounter ``congruent with'' or ``different than'' in the documents (as
opposed to ``congruent to'' and ``different from'' respectively.) Is
this really Standard American English?
Another general remark is that Chapter 1 and Chapter 2 do not stand very
well apart from Chapter 3 -- there are too many functions mentioned in
passing which are never defined in any further fashion (or even
mentioned again!) This certainly makes for rather hard reading and
comprehension.
1-22 2nd PP in `Intro to methods': The first and second sentences
seem to be too directly contradictory. I would change the first to
``A method object is not NECESSARILY a function an IN GENERAL cannot be
invoked as a function.''
1-25 To this reader, the statement in the 4th enumerated PP that ``The
checking of the validity of keyword names is done in the generic
function, not in each method'' seems inconsistent with the second PP on
1-26 ``If a method is passed a keyword argument is does not accept, an
error is signaled.'' Is the indent to draw some distinction between &key
args from DEFGENERIC and those which come from random DEFMETHODs? If
so, this should be made a lot clearer.
1-31 2nd PP. ``to the :method-combination option to defgeneric or TO
THE :METHOD-COMBINATION OPTION TO any of the other forms that specify
generic function options.'' The uppercase text seems redundant.
1-31 5th PP. I would replace this with ``The simple build-in method
combination types COULD HAVE BEEN defined...''
1-32 <foo>
1-33 Penultimate PP. I am probably just plain confused on this point,
but is it possible that ``and instances of the classes standard-method,
...'' should read just ``the classes standard-method, ...''? The
reference to standard-method in the following bulleted PP reinforces my
probably-mistaken belief.
1-39 3rd PP. I question the use of the word ``captured'' (which occurs
in other places in both Chapters 1 and 2.) ``Inherited'' seems more
straight-forward to me. This is probably just a personal preference.
1-39 Table. The last line would seem to imply that the defaulted
initlist must always be '(a 1 a 2 b 2), ruling out the `optimization'
(a 1 b 2). Is this the intent? It seems to unnecessarily constrain the
behaviour of default-initargs methods.
1-39 The section `Shared-Initialize' The introduction of this section at
this point seems very unmotivated. Nowhere above (except by implication
of the `--'-bulleted PPs on 1-37) is it made clear that
shared-initialize is an `underlying' method called by all the various
(re)initialization methods. Some small preamble at the beginning of
this section would make a first-time reading of the the spec somewhat
easier.
At this point I suppose I might as well express my misgivings about
the name `shared-initialize' -- it seems to imply to me something to do
with `shared' (ie class-allocated) slots or something like that. For
what it's worth, I'll state that the names `initialize-slots,'
`basic-initialize' and even `common-initialize' (or even
`initialize'!) appeal to me more than `shared-initialize.'
1-39 Last PP. I would write ``The second argument to shared-initialize
may be one of the following:''
1-40 First (bulleted) PP. What if the instance doesn't have a slot with
named by one of the elements of the list? Is it ``an error?'' Is
slot-missing called?
1-40 4th bulleted PP. It should be noted that ``This happens regardless
of whether or not the slot is specified by the second argument.'' or
something along those lines -- make it completely clear that this first
step in initialization depends only on the &key initarg, not on the
slot-name-specification arg. I'd also like to see a similar comment in
the Chapter 2 doc for shared-initialize.
1-41 `Definitions of make-instance and initialize-instance'
I think that it would make the manual a lot easier to read if similar
sample definitions were provided for the other initializations methods
(reinitialize-instance, update-instance-for-xxx, ...) I think that
moving this section of sample definitions forward in the manual (perhaps
before the `shared-initialize' section, perhaps even very early in
`Objection Creation and Initialization') would provide much better
understanding of what the various generic functions do.
This would also somewhat alleviate my above-mentioned problems with
the unmotivated appearance of `shared-initialize.'
When I started reading from `Object Creation and Initialization' I
encountered a whole slew of names of generic functions on which I would
define methods, but no real reason for why I should want to do so for
around 7 more pages.
I personally find it much easier to be presented with an overall
framework of code and then later `fill in the blanks' by reading what
the purpose of the various functions are than to wade though pages of
passing references to lots of functions before discovering how they fit
together and how they are supposed to be useful.
1-41 Definition of make-instance. Is nobody else bothered by the fact
that the use DEFAULT-INITARGS may be a consful operation in the presence
of :default-initargs? It would be very easy for the evaluation of
DEFAULT-INITARGS to consume more storage (to construct a merged initargs
list) than that of ALLOCATE-INSTANCE does in creation of the instance
itself!
My first reaction to this is to suggest a definition like:
(defmethod make-instance ((class standard-class) &rest initargs)
(apply #'with-defaulted-initargs
(lambda (&rest defaulted-initargs)
...initarg error-checking code...
(let ((instance (apply #'allocate-instance
class defaulted-initargs)))
(apply #'initialize-instance instance defaulted-initargs)
instance))
class initargs))
[where any implementation worth its salt would provide some way to
declare the dynamic extent of the INITARGS argument and the
LAMBDA-expression.]
Of course there are other ways to do this sort of thing.
I don't believe that the permissible optimizations mentioned are
sufficient to stop me worrying about this point.
So, has nobody else considered this issue, or does nobody else
consider it an issue?
1-41 Last PP. What ``certain optimizations are permitted.'' Nothing is
mentioned here or in the Chapter 2 description of initialize-instance to
explain what these might be, any how they might affect writers of
methods on initialize-instance or shared-initialize. The Chapter 2
description of shared-initialize explains this -- there should be some
xref.
1-42 Last PP. I found this hard to read. Suggestion:
``As a result of various optimizations, not all of the functions and
methods involved in initialization need necessarily be called on every
call to {\bf make-instance} and, if called, they may not receive exactly
the arguments that one would expect based on the sample implementation
above.''
The example of a permitted optimization is bogus, because
check-keyword-arguments is not a method, and so the user has no business
redefining it, and so user methods have no way of telling whether it has
already been called or not (since it is stated that it won't signal an
error.)
My feeling is that the vagueness in this section is very
unpleasant, and quite inconsistent with the general precision in the
rest of the document. I have some ideas on how to improve this, if
there is any interest in re-opening this issue and in listening to them.
1-43 6th PP. The aside ``This two-step process ...'' disrupts the
description of what the process is. Is should be moved below, after the
sentence ``... and other user-defined actions.''
1-44 6th PP, 1-46 last PP, 1-48 4th PP.
I find these incredibly disjointed. For starters, only half of the
contract of the ``system-supplied primary method'' is mentioned -- the
other half is to be found two paragraphs down -- in a different section!
Secondly, I don't think much would be lost be replacing each occurrence
of the intrusively-long
Initialization arguments are declared as valid by using the {\bf
:initarg} option to {\bf defclass} or by defining methods for {\bf
<method-name>} or for {\bf shared-initialize}. See the section
``Declaring the Validity of Initialization Arguments'' for more information.
with simply:
(See the section ``Declaring the Validity of Initialization Arguments''
for more information.)
Here's a suggested rewrite (I'd find code easier to read than this
turgid techno-English any day...):
There is a system-supplied primary method for {\bf
update-instance-for-redefined-class} whose parameter specializer for
its instance argument is the class {\bf standard-object}. This
method first checks the validity of initialization arguments and
signals an error if an initialization argument is supplied that is not
declared as valid. (See the section ``Declaring the Validity of
Initialization Arguments'' for more information.) Then it calls the
generic function {\bf shared-initialize} with arguments of the
instance, a list of names of the newly added slots, and the
initialization arguments it received.
The now-redundant second half of the descriptions of these methods (with
appear in the ``Customizing foo'' sections) could be replaced by just
Methods for {\bf shared-initialize} may be defined to customize class
redefinition. See the section ``Shared-Initialize'' for more
information.
Finally, just to be contentious (I'm not inviting replies):
* I'm still convinced (after two years (even after reading all the
archived mail on the subject)) that optionals should be defaulted in the
generic function rather than the methods.... Oh well.
* I think it is a real loss that there is no way of specifying an
`interface function' such as New Flavors has. The mess with the stupid
optional arg for DOCUMENTATION methods in chapter 2 is an example of
this.
* I'm aware of the problems they entail -- however I still find it a
pity that there is no provision for `private' methods and slots.
* I find the omission of defclass :constructors to be a significant
loss, based on past experience with implementing this sort of thing.
* I rely upon and heavily use New Flavors defun-in-method. I don't see
how I could get equivalent performance via the use of WITH-SLOTS (since
I don't believe (the equivalent of) usage of a mapping table will be done
outside of method bodies.)
* I think that the use of STANDARD method combination for the various
initialization methods is a mistake. It is too easy (for a ready
example, see the mistake Moon pointed out in <380731.880518.MOON@AI.AI.MIT.EDU>
about 2-15) to bash the useful system-defined method. It is not at all
clear to me that it is ever useful to do this deliberately -- the only
thing it could do (which could not be done by defining an `auxiliary'
method on it or on shared-initialize) is inhibit error-checking.
I hold that the `two-pass' method-combination used in Flavors for
initialize-instance is the right sort of thing: initialize-instance and
reinitialize-instance should use `progn-with-:after' method combination,
and update-instance-for-redefined-class and
update-instance-for-different-class should use `progn-with-:before'
method combination (I can't think of a use for :after methods on these
gf's.)
Besides, use of non-STANDARD method-combination would actually show
readers that all this method-combination hair is actually good for
anything!
* I find the `evalness' of define-method-combination very disturbing.
It seems to me that a full lisp compiler or evaluator will need to be
present in any world into are loaded methods on generic functions which
use user-defined method-combination. I would -very- much like to be
convinced that this isn't the case.
* IWBNI GET and (SETF GET) were made generic, though I suppose the same
sort of argument could be made for dozens of other CLtL functions.
∂20-May-88 1703 Common-Lisp-Object-System-mailer Comments on new draft chapter 1 (dated May 13 20:53)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 May 88 17:03:03 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 408054; 20 May 88 20:02:25 EDT
Date: Fri, 20 May 88 20:02 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Comments on new draft chapter 1 (dated May 13 20:53)
To: Richard Mlynarik <MLY@AI.AI.MIT.EDU>
cc: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <19880520213530.4.MLY@PERON.AI.MIT.EDU>
Message-ID: <19880521000213.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 20 May 88 17:35 EDT
From: Richard Mlynarik <MLY@AI.AI.MIT.EDU>
Comments on a subset of your comments, not to imply that the remainder
should be ignored. In general I agree with them.
1-25 To this reader, the statement in the 4th enumerated PP that ``The
checking of the validity of keyword names is done in the generic
function, not in each method'' seems inconsistent with the second PP on
1-26 ``If a method is passed a keyword argument is does not accept, an
error is signaled.'' Is the indent to draw some distinction between &key
args from DEFGENERIC and those which come from random DEFMETHODs? If
so, this should be made a lot clearer.
I missed this one in my recent review of the document.
I believe the word "method" in the 2nd pp on 1-26 is a typo and should
be "generic function." Clearer would be "If a generic function is passed
a keyword argument that no applicable method accepts, an error is signaled."
Also, for consistency with the last paragraph on CLtL p.62, it should be
"an error should be signaled" rather than "an error is signaled." Not
that I am a fan of implementations that allow you to turn off error checking.
1-32 <foo>
I don't follow.
1-33 Penultimate PP. I am probably just plain confused on this point,
but is it possible that ``and instances of the classes standard-method,
...'' should read just ``the classes standard-method, ...''? The
reference to standard-method in the following bulleted PP reinforces my
probably-mistaken belief.
No, the text is correct as it stands. Everything involving meta objects is
inherently confusing because it's difficult to keep the two levels straight.
1-39 3rd PP. I question the use of the word ``captured'' (which occurs
in other places in both Chapters 1 and 2.) ``Inherited'' seems more
straight-forward to me. This is probably just a personal preference.
"Captured" refers to lexical capturing, not class inheritance. I'm not
sure it's necessary to repeat "captured" periodically; we could just leave
it to the explanation on 1-10 and again on 1-35.
1-39 Table. The last line would seem to imply that the defaulted
initlist must always be '(a 1 a 2 b 2), ruling out the `optimization'
(a 1 b 2). Is this the intent? It seems to unnecessarily constrain the
behaviour of default-initargs methods.
"a 2" was not put in by defaulting, it was supplied explicitly by the caller.
Given that, I don't think we want to change the table.
1-39 The section `Shared-Initialize' The introduction of this section at
this point seems very unmotivated. Nowhere above (except by implication
of the `--'-bulleted PPs on 1-37) is it made clear that
shared-initialize is an `underlying' method called by all the various
(re)initialization methods. Some small preamble at the beginning of
this section would make a first-time reading of the the spec somewhat
easier.
The spec is deliberately made difficult to read to discourage people from
making implementations without reading it slowly and carefully :-)
At this point I suppose I might as well express my misgivings about
the name `shared-initialize' -- it seems to imply to me something to do
with `shared' (ie class-allocated) slots or something like that. For
what it's worth, I'll state that the names `initialize-slots,'
`basic-initialize' and even `common-initialize' (or even
`initialize'!) appeal to me more than `shared-initialize.'
The false connotation of shared slots is the same comment I had. However,
all four of your suggested alternatives have problems, and we spent so much
time trying to find a better name that I think we should go with the one
we have for this round of the document, and let X3J13 instruct us to change
it if they so desire.
1-40 First (bulleted) PP. What if the instance doesn't have a slot with
named by one of the elements of the list? Is it ``an error?'' Is
slot-missing called?
You're right, we need to specify this. Let's make it "the results are
unspecified."
1-41 Definition of make-instance. Is nobody else bothered by the fact
that the use DEFAULT-INITARGS may be a consful operation in the presence
of :default-initargs? It would be very easy for the evaluation of
DEFAULT-INITARGS to consume more storage (to construct a merged initargs
list) than that of ALLOCATE-INSTANCE does in creation of the instance
itself!
Of course. But the spec defines the semantics of the language, not how
to do semantics-preserving implementation-dependent optimizations. I
don't think complicating the specification to make it slightly more
obvious how to optimizations is a good tradeoff. Also, with reasonable
garbage collectors, which are starting to emerge even on traditional
hardware, consing is not such a burden.
Finally, just to be contentious (I'm not inviting replies):
Yes, CLOS definitely has that design-by-committee aroma.
* I find the `evalness' of define-method-combination very disturbing.
It seems to me that a full lisp compiler or evaluator will need to be
present in any world into are loaded methods on generic functions which
use user-defined method-combination. I would -very- much like to be
convinced that this isn't the case.
I don't understand your point. How is define-method-combination different
from defmacro in this respect? Perhaps you've been misled by the way the
spec describes everything as if it was interpreted into thinking that it
cannot be compiled?
∂20-May-88 2010 Common-Lisp-Object-System-mailer check-keyword-arguments
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 20 May 88 20:09:12 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191392; Fri 20-May-88 23:08:50 EDT
Date: Fri, 20 May 88 23:08 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: check-keyword-arguments
To: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: The message of 19 May 88 19:13 EDT from Dick Gabriel <RPG@SAIL.Stanford.EDU>
Message-ID: <19880521030857.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 19 May 88 1613 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I want to present one more alternative to the initargs checking
problem.
[Getting rid of check-initargs & successors, writing the code inline,
and putting it in chapter 3.]
This sounds good to me, with a couple modifications suggested below.
Let's go with it.
We could introduce a new generic function called valid-keywords, which
takes an object; if it is something with keywords (like a generic
function, a method, or a function), valid-keywords returns two values: a
list of the explicitly named keywords and a boolean which states whether
&allow-other-keys had been specified in the definition.
function-keywords would be a better name. Otherwise okay.
I have no quarrel with the dual return values.
[Yes, I know (subtypep 'method 'function) => nil t. Nonetheless,
in this context the method is used in a functionesque way.]
I assume method-applicable-keywords, p.27 of the most recent draft
of ch.3 that I've seen (the one handed out at X3J13 in March), would
go away.
Then we could write make-instance like this:
(defmethod make-instance ((class standard-class) &rest initargs)
(setq initargs (default-initargs class initargs))
(let* ((proto (class-prototype class))
(methods
(union
(compute-applicable-methods #'allocate-instance `(,class))
(union
(compute-applicable-methods #'initialize-instance `(,proto nil))
(compute-applicable-methods #'shared-initialize `(,proto))))))
I think you want append rather than union, since there won't be any
methods in common between distinct generic functions. Also the args for
initialize-instance and shared-initialize have accidentally gotten
interchanged.
(unless
(subsetp
(let ((keys '()))
(do ((plist initargs (cddr plist)))
((null plist) keys)
(push (car plist) keys)))
(union
(class-slot-initargs class)
(reduce #'union (mapcar #'valid-keywords methods))))
(error ...)))
(let ((instance (apply #'allocate-instance class initargs)))
(apply #'initialize-instance instance initargs)
instance))
∂20-May-88 2206 Common-Lisp-Object-System-mailer check-keyword-arguments
To: common-lisp-object-system@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I think Moon's suggestion for the name FUNCTION-KEYWORD is acceptable.
Here is the corrected code (Having Moon around to read code is
almost as good as having a computer. In fact, it's better because
sometimes he cracks a joke.):
(defmethod make-instance ((class standard-class) &rest initargs)
(setq initargs (default-initargs class initargs))
(let* ((proto (class-prototype class))
(methods
(append
(compute-applicable-methods #'allocate-instance `(,class))
(compute-applicable-methods #'initialize-instance `(,proto))
(compute-applicable-methods #'shared-initialize `(,proto nil)))))
(unless
(subsetp
(let ((keys '()))
(do ((plist initargs (cddr plist)))
((null plist) keys)
(push (car plist) keys)))
(union
(class-slot-initargs class)
(reduce #'union (mapcar #'function-keywords methods))))
(error ...)))
(let ((instance (apply #'allocate-instance class initargs)))
(apply #'initialize-instance instance initargs)
instance))
∂21-May-88 0017 Common-Lisp-Object-System-mailer Mlynarik's comments
To: common-lisp-object-system@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
First I'll address the general grammatical comments. As far as I can tell
by reading the OED, ``congruent with'' is standard British English. Using
Webster's Second Unabridged - the most prescriptive American English
dictionary - I find ``congruent with'' used in general contexts and in
most mathematical contexts. My perusal of math texts seems to indicate
``congruent to'' is acceptable when discussing number theory. I cannot
find explicit grammatical justification for ``congruent to'' in any
context. Because we are not talking about number theory, I don't believe
any changes are necessary.
It is currently correct to use the following rules for ``different'': The
phrase ``different from'' is used when introducing a phrase while
``different than'' is used when introducing a clause. My references claim
``different from'' and ``different than'' have both appeared for the
last 300 years. British usage admits ``different to.''
Note there is no use of ``different than'' (or ``different from'')
in chapter 1.
To comment further on the grammar in chapters 1 and 2. Linda and I are
both relatively careful writers in terms of grammar, and I can assure you
that we have not dashed off this piece. Furthermore, we have engaged copy
editors to proofread major drafts of these chapters before they are sent
out. The style of writing might be academic, but I believe it corresponds
to acceptable Amercian English in all cases, and even the editors of the
OED now accept American usage as standard.
The remainder of this message is a response to Richard's comments. I have left
out specific comments to which Moon responded with remarks with which I
agree.
Richard writes:
``1-22 2nd PP in `Intro to methods': The first and second sentences
seem to be too directly contradictory. I would change the first to
``A method object is not NECESSARILY a function an IN GENERAL cannot be
invoked as a function.'' ''
The sentences in question are:
``A method object is not a function and cannot be invoked as a function. An
implementation may extend the \OS\ so that method objects are functions.''
The reason it is stated this way is that no one writing portable code can
take them to be functions, but we do not require them to not be functions
in all implementations. If we wrote it your way then someone could
legitimately understand that within a single implementation a particular
method object may or may not be a function.
The style we use consistently throughout is to state a constraint
and then allow extensions.
Richard writes:
``1-25 To this reader, the statement in the 4th enumerated PP that ``The
checking of the validity of keyword names is done in the generic
function, not in each method'' seems inconsistent with the second PP on
1-26 ``If a method is passed a keyword argument is does not accept, an
error is signaled.'' Is the indent to draw some distinction between &key
args from DEFGENERIC and those which come from random DEFMETHODs? If
so, this should be made a lot clearer.''
Moon's remark is correct and the passage has been repaired.
Richard writes:
``1-31 2nd PP. ``to the :method-combination option to defgeneric or TO
THE :METHOD-COMBINATION OPTION TO any of the other forms that specify
generic function options.'' The uppercase text seems redundant.''
It is redundant and intentionally so: You cannot possibly misread
the current version. A misreading would be
``To specify that a generic function is to use one of these method
combination types, the name of the method combination type is given as the
argument ... to any of the other forms that specify generic function
options.''
Richard writes:
``1-31 5th PP. I would replace this with ``The simple build-in method
combination types COULD HAVE BEEN defined...'' ''
``Could have been'' but weren't? Your rewrite talks about an implementation
choice that may or may not be relevant, whereas the current language
discusses semantics.
Richard writes:
``1-32 <foo>''
I agree with Richard on the weirdness of this description, but
I could not (and still cannot) think of a more precise approach to
describing this. I have spent weeks on the bulleted item over the
last 2 years.
Richard writes:
``1-39 Last PP. I would write ``The second argument to shared-initialize
may be one of the following:'' ''
Right.
Richard writes:
``1-39 The section `Shared-Initialize' The introduction of this section at
this point seems very unmotivated. Nowhere above (except by implication
of the `--'-bulleted PPs on 1-37) is it made clear that
shared-initialize is an `underlying' method called by all the various
(re)initialization methods. Some small preamble at the beginning of
this section would make a first-time reading of the the spec somewhat
easier.''
Right. I added such an introduction to shared-initialize early
in the section.
Richard writes:
``1-40 4th bulleted PP. It should be noted that ``This happens regardless
of whether or not the slot is specified by the second argument.'' or
something along those lines -- make it completely clear that this first
step in initialization depends only on the &key initarg, not on the
slot-name-specification arg. I'd also like to see a similar comment in
the Chapter 2 doc for shared-initialize.''
Right.
Richard writes:
``1-41 Last PP. What ``certain optimizations are permitted.'' Nothing is
mentioned here or in the Chapter 2 description of initialize-instance to
explain what these might be, any how they might affect writers of
methods on initialize-instance or shared-initialize. The Chapter 2
description of shared-initialize explains this -- there should be some
xref.''
I thought it already cross-references to shared-initialize.
Richard writes:
``1-42 Last PP. I found this hard to read. Suggestion....''
This paragraph has been rewritten based on the newthink on the
check-initargs problem.
Richard writes:
`` My feeling is that the vagueness in this section is very
unpleasant, and quite inconsistent with the general precision in the
rest of the document. I have some ideas on how to improve this, if
there is any interest in re-opening this issue and in listening to them.''
Yes, I would like to hear your ideas.
Richard writes:
``1-43 6th PP. The aside ``This two-step process ...'' disrupts the
description of what the process is. Is should be moved below, after the
sentence ``... and other user-defined actions.'' ''
This paragraph is now different enough that this comment isn't as valid.
In particular, other circumstances have been added in which the process
can start up, and the discussion of when it can happen is the current
focus of the paragraph.
Richard writes:
``1-44 6th PP, 1-46 last PP, 1-48 4th PP.
I find these incredibly disjointed. For starters, only half of the
contract of the ``system-supplied primary method'' is mentioned -- the
other half is to be found two paragraphs down -- in a different section!
....''
Good idea. I've so modified the sections.
-rpg-
∂21-May-88 0651 Common-Lisp-Object-System-mailer Comments on current state of Initialization.
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 21 May 88 06:51:05 PDT
Received: by labrea.stanford.edu; Sat, 21 May 88 06:51:30 PDT
Received: from bhopal.lucid.com by edsel id AA20037g; Sat, 21 May 88 06:40:47 PDT
Received: by bhopal id AA08392g; Sat, 21 May 88 06:44:29 PDT
Date: Sat, 21 May 88 06:44:29 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805211344.AA08392@bhopal.lucid.com>
To: common-lisp-object-system@sail.stanford.edu
Subject: Comments on current state of Initialization.
Why should there still be three initialization protocls: "shared-initialize",
"initialize-instance", and "reinitialize-instance" (sp?).
Why not just "initialize-instance" with a keyword argument for whether or
not it is a first-time initialization? In each case, the specialization
needed is over the instance, and not over the slots-for-initforms argument,
or the initargs argument, or any other arugment. And so _most_ of the
processing will be the same regardless of whether the caller is make-instance
or one of the update-instance-for-<munged>-class functions (i.e., whether
initializing afresh or whether re-initializing). In fact, for many classes
I would guess that the particular list given as the 'slots-for-initforms'
argument would adequately cover any necessary distinctions between fresh
allocation and "update-instance-for-<munged>-class". Direct user calls, if
any, could pass this keyword argument, rather than decide between two
differently named functions.
I presume that the main primary method is the one whose chief purpose is to
set slots, first from the initargs and then from the initforms, and that this
wouldn't need to be modified by the user. [In fact, letting the user change
this primary method is probably a mistake.] Again, I would guess that most
user :after methods wouln't be concerned with the distinction between
"fixing up" the initialization of a fresh instance, and that of "fixing up"
the re-setting of slots on an "old" instance; in each case, the more
important information is in the 'slots-for-initforms' argument.
In short, what I fail to see is any justification for hairing up the
protocol to inject a generic function that seems to have no particular
user benefit: reinitialize-instance. Looking over back mail, I find
this one comment from Danny:
Date: 8 Apr 88 15:37 PDT
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Subject: Re: (re)initialization revisited
In-Reply-To: kempf@Sun.COM's message of Thu, 07 Apr 88 12:13:45 -0700
To: kempf@Sun.COM
Cc: common-lisp-object-system@SAIL.STANFORD.EDU
Jim proposes removing some functions in the spec. I sympathize with this
as a general goal. But in this case I think it is misguided. There are
really four concepts
1) initializate (make a brand new instance have the right state)
2) reinitialize (make an old instance have a "standard" starting state)
3) class-changed (make a change from one form of current instance to another)
4) update-instance-structure (make an appropriate current instance from an
outdated instance.
Because there are four concepts, there must be four entries so that users
can change what is done for each. Collapsing concepts into a commonly
named fn just causes confusion.
. . .
Reinititializing must potentially take into account old values on slots.
Initialization never has to. We introduced the general concept because we
had two examples in CLOS itself that require it: instances of
standard-class, and instances of standard-generic-function. Both must
take into account previous state of the objects to be changed.
But still, this is not justification for imposing a complexity that
will almost never be used by the end user, and for which there is an
adequate alternative: keyword argument to initialize-instance. Note
that there is no need to split off re-initialization due to a difference
in the ways in which it might be specialized.
-- JonL --
∂21-May-88 1602 Common-Lisp-Object-System-mailer define-method-combination
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 21 May 88 16:02:23 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191452; Sat 21-May-88 19:01:56 EDT
Date: Sat, 21 May 88 19:01 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: define-method-combination
To: Richard MlYNarIk <Mly@AI.AI.MIT.EDU>
cc: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <19880521191828.5.MLY@PERON.AI.MIT.EDU>
Message-ID: <19880521230158.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sat, 21 May 88 15:18 EDT
From: Richard MlynBaOrik <Mly@AI.AI.MIT.EDU>
[common-lisp-object-system@SAIL.STANFORD.EDU removed]
[Added back since I thought it was useful for the whole list to see
the reply. I don't expect I'm embarrassing you.]
Date: Fri, 20 May 88 20:02 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
* I find the `evalness' of define-method-combination very disturbing.
It seems to me that a full lisp compiler or evaluator will need to be
present in any world into are loaded methods on generic functions which
use user-defined method-combination. I would -very- much like to be
convinced that this isn't the case.
I don't understand your point. How is define-method-combination different
from defmacro in this respect? Perhaps you've been misled by the way the
spec describes everything as if it was interpreted into thinking that it
cannot be compiled?
I'm wondering how add-method works.
If one does a random add-method to a generic function (say by loading a
file containing a defmethod form) then whenever the combined
(`effective') method is created (at instance instantiation time or
whenever) something has got to look at the lisp code produced by the
`macroexpansion' of a define-method-combination form. This
macroexpasion can't be performed any earlier, because it depends on the
applicable methods.
That's quite a reasonable concern to have, however we've thought of it.
The compiler can anticipate what add-method calls are going to be
produced by forms the compiler has seen, such as defmethod forms. The
code resulting from method-combination can be predicted at compile time
and compiled then, with a simple mechanism to make sure at load time
that that pregenerated code gets used. This is how it works in Flavors,
so that's an existence proof.
Of course if a program calls add-method at run time in a way the compiler
can't anticipate, such techniques can't win. But I'd say that kind of
program, which changes its structure at run time, should not be surprised
to depend on having a compiler at run time.
As I see it, either the lisp evaluator is used whenever the combined
method is called or else the lisp code produced by
define-method-combination has to be turned into something executable by
`the machine.'
It's also true that an evaluator different from the Lisp evaluator can
be used. For example, the form returned by the method combination
function can be recognized as an instance of a pattern and the effective
method can be a closure of a preexisting function that knows how to
"evaluate" such forms; the enclosed variables typically have methods or
lists of methods as their values. The preexisting functions can even be
generated automatically when the system is compiled, from declarative
specifications (arrange for x type of method combination to work with n
applicable methods in role z). Some types of method combination work
this way in Flavors in 7.2 [oh, I see you know that], and I'm told PCL
also works this way. I assume that CLOS can work this way, too, using
the world's simplest pattern matcher to recognize forms returned by
method combination functions.
∂21-May-88 1605 Common-Lisp-Object-System-mailer Comments on current state of Initialization.
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 21 May 88 16:04:55 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191453; Sat 21-May-88 19:04:12 EDT
Date: Sat, 21 May 88 19:04 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Comments on current state of Initialization.
To: Jon L White <edsel!jonl@labrea.stanford.edu>
cc: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <8805211344.AA08392@bhopal.lucid.com>
Message-ID: <19880521230422.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sat, 21 May 88 06:44:29 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Why should there still be three initialization protocls: "shared-initialize",
"initialize-instance", and "reinitialize-instance"?
[Summary: replace reinitialize-instance with a keyword argument to
initialize-instance --Moon]
Two reasons come immediately to mind: shared-initialize is also used when a
class is redefined or change-class is called; reinitialize-instance is to be
called directly by the user, but initialize-instance cannot be (review how
the keyword arguments get validated).
∂21-May-88 1923 Common-Lisp-Object-System-mailer define-method-combination
Received: from XX.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 May 88 19:23:33 PDT
Received: from PERON.AI.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 21 May 88 22:24-EDT
Date: Sat, 21 May 88 22:27 EDT
From: Richarrd MLYnaRIk <Mly@AI.AI.MIT.EDU>
Subject: define-method-combination
To: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <19880521230158.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19880522022721.6.MLY@PERON.AI.MIT.EDU>
Before I launch into the usual tirade, I'd like to make a suggestion
which might have some hope of being considered:
define-method-combination should accept an option
(:generic-function <symbol>)
and bind <symbol> to the relevant generic function.
This has much the same flavour as the existing :arguments option.
I think that this is a nicer solution than binding
a magic variable named `generic-function'.
======================================================================
I only partially believe what Moon says about define-method-combination.
On the whole, I find his arguments unfortunate sorts of thing to have to
claim, especially when there are another ways of declaring method
combination this which avoids this sort of problem. (By constructing
closures rather than s-expressions.)
I do believe his arguments as applied to system-predefined
method-combination -- after all, and as he says, we have Flavors as an
existence proof.
On the other hand, as long as I've been using lisp machines (up to this
very day) I've encountered combined methods which weren't caught at
compile-time. So I suppose we should say that we would have Flavors as
existence proof in principle...
I very much doubt that a user will in fact be able to declare enough to
the system to generate the same quality of code as the specially-
recognised predefined system method combination types -- let
alone that s/he would be able to declare this is any portable way!
I realize that CLOS is only specifying semantics, but why make things
harder than they need be, so hard they they need a Sufficiently Smart
Compiler Sufficiently Useful Magic-Unspecified-Declarations/
Sufficiently Powerful Magic-Unspecified-Pattern-Matching-Language/ etc?
(For years there has been talk about sufficiently smart compilers taking
all of my troubles away, but I've yet to see evidence of such things.)
My overall fear is that this sort of approach will create two classes of
programs -- those which use the system's predefined method combination
types and standard method definition (such as defmethod with
:method-class standard-method) and those which use anything else. The
first class of programs can expect a much higher level of support than
the latter, because the compiler has been taught special tricks. I like
to think that one of the aims of CLOS in general (though Chapter 3-style
specifications) is to expose as much of the underlying works as is
necessary to allow non-`standard' classes/method-combination/etc to be
able to expect a level of support which is at least of the same order of
magnitude as that provided by the system. This certainly does not seem
to be the case with user-defined method-combination types.
(I know there are limits to this argument -- for example I doubt that J.
Random Generic-function Metaclass could expect the same performance as
implementation-tuned standard-generic-function.)
However, if user-defined method combination is to be a toy which works
1/1000th as well as system-defined method combination (because it has to
call out to the evaluator or otherwise do a bunch of unnecessary hair at
run time or require the presence of a full lisp compiler) then why
bother specifying it at all? I'm sure most people will be happy with a
few standard method combination types -- why clutter up the world and
raise people's expectations with something which can't be guaranteed to
work very well? Especially, why clutter the world so much the EVAL
becomes required (when nothing else in CLtL except for the section on
the evaluator seems to require such a horrible thing)?
BTW I've looked at the pattern-matchers (by no means ``the world's
simplest'' -- PCL's uses a real code-walker) in both PCL and Flavors and
still doubt that they can do enough before they become full lisp
compilers. (When Flavor's pattern-matcher punts, it ends up calling
compile.)
I don't believe Moon's argument that something less than a full lisp
evaluator will do to interpret user-defined effective methods -- it is
trivial to define a method combination type (and not even a particularly
contrived one) which will defeat this.
I guess Scheme has gone badly to my brain -- the mere hint of run-time
evaluation/compilation makes me feel ill (the symptoms are flames coming
from the mouth.) There is another reason, though: I have recently had
very bad experiences with a very large piece of software which suffered
and suffered (and made me suffer) because of the way it called out to
the evaluator.
Anyway, this whole issue was originally filed under the
``Just to be contentious'' label -- I didn't expect and still do not
expect to convince anybody.
I am not going to continue to flame about this.
∂23-May-88 0644 Common-Lisp-Object-System-mailer Re: check-keyword-arguments
Received: from ti.com by SAIL.Stanford.EDU with TCP; 23 May 88 06:44:34 PDT
Received: by ti.com id AA26663; Mon, 23 May 88 08:43:54 CDT
Received: from Jenner by tilde id AA28453; Mon, 23 May 88 08:31:19 CDT
Message-Id: <2789386229-306446@Jenner>
Date: Mon, 23 May 88 08:30:29 CDT
From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
To: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Cc: common-lisp-object-system@SAIL.STANFORD.EDU
Subject: Re: check-keyword-arguments
In-Reply-To: Msg of 20 May 88 2206 PDT from Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Date: 20 May 88 2206 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: check-keyword-arguments
(defmethod make-instance ((class standard-class) &rest initargs)
(setq initargs (default-initargs class initargs))
(let* ((proto (class-prototype class))
(methods
(append
(compute-applicable-methods #'allocate-instance `(,class))
(compute-applicable-methods #'initialize-instance `(,proto))
(compute-applicable-methods #'shared-initialize `(,proto nil)))))
(unless
(subsetp
(let ((keys '()))
(do ((plist initargs (cddr plist)))
((null plist) keys)
(push (car plist) keys)))
(union
(class-slot-initargs class)
(reduce #'union (mapcar #'function-keywords methods))))
(error ...)))
(let ((instance (apply #'allocate-instance class initargs)))
(apply #'initialize-instance instance initargs)
instance))
I agree, expect that the second value returned by function-keywords needs
to be looked at. Something like this would work (I think):
(defmethod make-instance ((class standard-class) &rest initargs)
(setq initargs (default-initargs class initargs))
(let* ((proto (class-prototype class))
(methods
(append
(compute-applicable-methods #'allocate-instance `(,class))
(compute-applicable-methods #'initialize-instance `(,proto))
(compute-applicable-methods #'shared-initialize `(,proto nil)))))
(unless
(block check-keys
(let ((valid-keys (class-slot-initargs class)))
(dolist (method methods)
(multiple-value-bind (keys allow-other-keys-p)
(function-keywords method)
(if allow-other-keys-p
(return-from check-keys t)
(setf valid-keys (union keys valid-keys)))))
(subsetp
(let ((keys '()))
(do ((plist initargs (cddr plist)))
((null plist) keys)
(push (car plist) keys)))
valid-keys)))
(error ...)))
(let ((instance (apply #'allocate-instance class initargs)))
(apply #'initialize-instance instance initargs)
instance))
Patrick.
∂23-May-88 0842 Common-Lisp-Object-System-mailer Re: define-method-combination
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 23 May 88 08:42:19 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
id AA04663; Mon, 23 May 88 08:41:00 PDT
Received: from suntana.sun.com by snail.sun.com (4.0/SMI-3.2)
id AA15995; Mon, 23 May 88 08:38:27 PDT
Received: from localhost by suntana.sun.com (3.2/SMI-3.2)
id AA04572; Mon, 23 May 88 08:33:04 PDT
Message-Id: <8805231533.AA04572@suntana.sun.com>
To: Richarrd MLYnaRIk <Mly@AI.AI.MIT.EDU>
Cc: common-lisp-object-system@SAIL.STANFORD.EDU
Subject: Re: define-method-combination
In-Reply-To: Your message of Sat, 21 May 88 22:27:00 -0400.
<19880522022721.6.MLY@PERON.AI.MIT.EDU>
Date: Mon, 23 May 88 08:33:01 -0700
From: kempf@Sun.COM
>On the other hand, as long as I've been using lisp machines (up to this
>very day) I've encountered combined methods which weren't caught at
>compile-time. So I suppose we should say that we would have Flavors as
>existence proof in principle...
Unfortunately, I suspect that you may be right about this. However, I don't
necessarily believe that this makes user defined method combination types
useless. Certainly, for prototype or experimental code, where performance
is not as critical, they should be useful. And CLOS has been designed
with the needs of experimentalists in mind. There may even be some
applications which don't mind having a full evaluator or compiler around.
In fact, how many Lisp applications run today *without* a full evaluator
or compiler around (rhetorical question, very few I suspect).
>I realize that CLOS is only specifying semantics, but why make things
>harder than they need be, so hard they they need a Sufficiently Smart
>Compiler Sufficiently Useful Magic-Unspecified-Declarations/
>Sufficiently Powerful Magic-Unspecified-Pattern-Matching-Language/ etc?
>(For years there has been talk about sufficiently smart compilers taking
>all of my troubles away, but I've yet to see evidence of such things.)
When somebody manages to convince a funding agency like DARPA that
research on advanced Lisp compilers is important, it will happen.
Until then, forget it. Lots of people have plenty of ideas about
how to make Lisp compilers Sufficiently Smart, unfortunately, maintenance
of existing compilers, addition of features (like multiprocessing) and
environmental support have taken precedence in the commercial field,
because that is what customers are asking for. The way things are
currently going, we should be happy if a product quality CLOS is
available within a reasonable amount of time, and I'm not talking about
the technical side of implementing it.
>My overall fear is that this sort of approach will create two classes of
>programs -- those which use the system's predefined method combination
>types and standard method definition (such as defmethod with
>:method-class standard-method) and those which use anything else. The
>first class of programs can expect a much higher level of support than
>the latter, because the compiler has been taught special tricks. I like
>to think that one of the aims of CLOS in general (though Chapter 3-style
>specifications) is to expose as much of the underlying works as is
>necessary to allow non-`standard' classes/method-combination/etc to be
>able to expect a level of support which is at least of the same order of
>magnitude as that provided by the system. This certainly does not seem
>to be the case with user-defined method-combination types.
This is a goal, however, there is a real question of how much the
underlying works can be exposed without constraining the implementation
so much that the standard system defined generic functions and method
combinations can't be compiled efficiently. Unless someone does an
existence proof, it is unlikely that we will really know, because a
paper specification might miss something important. After having tuned
up PCL, I know that the level of metaobject support in PCL can be implemented
very efficiently on stock hardware, however, the version of PCL I used
didn't have method combination, much less user defined method combination.
Of course, any attempt to add additional features invalidates the existence
proof.
>I guess Scheme has gone badly to my brain -- the mere hint of run-time
>evaluation/compilation makes me feel ill (the symptoms are flames coming
More importantly for commercial purposes, C++. That's the competition.
While it is unlikely that we will be able to get performance comparible
to C++ on the first round, given your Sufficiently Smart compiler, it
should be possible to approach it. Whether a Sufficiently Smart CLOS
compiler happens, however, is again a question of priorities.
jak
∂23-May-88 0948 Common-Lisp-Object-System-mailer Re: check-keyword-arguments
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 May 88 09:48:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 MAY 88 09:47:58 PDT
Date: 23 May 88 09:46 PDT
Sender: Bobrow.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Subject: Re: check-keyword-arguments
In-reply-to: Dick Gabriel <RPG@SAIL.Stanford.EDU>'s message of 20 May 88 22:06
PDT
To: RPG@SAIL.Stanford.EDU
cc: common-lisp-object-system@SAIL.Stanford.EDU
Message-ID: <880523-094758-4593@Xerox>
I am happy to see this version of make-instance PROVIDED we put
compute-applicable-methods and function-keywords in chapter 2. I think both
provide features which are useful to programmers working with CLOS as it stands
rather than with possibly extending the system. compute-applicable-methods is
parallel to find-method, and function-keywords is similar to method-qualifiers,
both of which are in chapter 2. I mildly prefer the name method-keywords since
its argument is a method.I would also suggest find-applicable-methods to
parallel find-method.
∂23-May-88 1047 Common-Lisp-Object-System-mailer More Check-Keyword-Arguments
To: common-lisp-object-system@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I have no problems with compute-applicable-methods and function-keywords
being in chapter 2, except that we are on top of the two-week rule
and have to blast out to make it. Function-keywords is a good name because
it is a generic function, and some Common Lisps might extend it to CL functions.
I preferred valid-keywords because it did not talk about either functions or
methods.
-rpg-
∂23-May-88 1055 Common-Lisp-Object-System-mailer define-method-combination
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 23 May 88 10:55:02 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191675; Mon 23-May-88 13:54:24 EDT
Date: Mon, 23 May 88 13:54 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: define-method-combination
To: Richarrd MLYnaRIk <Mly@AI.AI.MIT.EDU>
cc: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <19880522022721.6.MLY@PERON.AI.MIT.EDU>
Message-ID: <19880523175424.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sat, 21 May 88 22:27 EDT
From: Richarrd MLYnaRIk <Mly@AI.AI.MIT.EDU>
Before I launch into the usual tirade, I'd like to make a suggestion
which might have some hope of being considered:
define-method-combination should accept an option
(:generic-function <symbol>)
and bind <symbol> to the relevant generic function.
This has much the same flavour as the existing :arguments option.
I think that this is a nicer solution than binding
a magic variable named `generic-function'.
I agree. I think this just got overlooked when :arguments was added,
because before that there wasn't any agreed-upon syntax for saying
things like this. Group: Is there still time to change this?
....
On the other hand, as long as I've been using lisp machines (up to this
very day) I've encountered combined methods which weren't caught at
compile-time.
And as long as I've been using Lisp, I've encountered files that use a macro
that has been changed, but no one remembered to recompile the file, so the
caller of the macro was not updated. Few people propose to remove macros
from Lisp for that reason. I just don't think your argument is relevant.
....
My overall fear is that this sort of approach will create two classes of
programs -- those which use the system's predefined method combination
types and standard method definition (such as defmethod with
:method-class standard-method) and those which use anything else. The
first class of programs can expect a much higher level of support than
the latter, because the compiler has been taught special tricks.
I agree that that could happen, but I see no reason why it must.
I like
to think that one of the aims of CLOS in general (though Chapter 3-style
specifications) is to expose as much of the underlying works as is
necessary to allow non-`standard' classes/method-combination/etc to be
able to expect a level of support which is at least of the same order of
magnitude as that provided by the system. This certainly does not seem
to be the case with user-defined method-combination types.
I agree with your first sentence, but don't see why you think
user-defined method-combination types are any different from anything
else. Also, you've changed your argument. First you said user-defined
method combination types require the existence of a compiler at load
time (and implicitly you assumed that all Lisps are like most of today's
(but not the 1950's!) Lisps, in that if you have a compiler at load
time, you cannot get rid of it at run time). Now you're saying that
user-defined method combination won't compile as efficiently as standard
method combination, an entirely different argument. I think your new
argument is analogous to saying that it's better to use DO than LOOP,
not because you like the syntax better, but because DO as a built-in
macro is likely to compile more efficient code than LOOP, as a
user-defined macro. That's even true to some extent with some
compilers, but few people change their whole programming style on the
basis of that kind of consideration, and in all the arguments against
LOOP I've heard over the years, I don't recall ever hearing that one.
I really believe that method combination is just like a macro.
However, if user-defined method combination is to be a toy which works
1/1000th as well as system-defined method combination (because it has to
call out to the evaluator or otherwise do a bunch of unnecessary hair at
run time or require the presence of a full lisp compiler)
Please, please, please do not be confused by the interpreter-oriented
presentation, any more than you would be confused by a Lisp textbook which
explained the language in interpretive terms and only introduced the compiler
in a late chapter. Semantics are easier to explain interpretively, but no
one proposes calling out to the evaluator in any real implementation.
then why
bother specifying it at all? I'm sure most people will be happy with a
few standard method combination types -- why clutter up the world and
raise people's expectations with something which can't be guaranteed to
work very well?
Change "method combination type" to "macro" and read your argument again.
Of course, there are people in the Scheme community who believe that argument.
I think Common Lisp is way past aspiring to that level of purity, though.
I don't believe Moon's argument that something less than a full lisp
evaluator will do to interpret user-defined effective methods -- it is
trivial to define a method combination type (and not even a particularly
contrived one) which will defeat this.
Of course. It's also trivial to write a program that cannot be compiled.
In practice, people who care about the issue you're concerned with don't
do those things.
∂23-May-88 1105 Common-Lisp-Object-System-mailer Re: define-method-combination
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 23 May 88 11:05:46 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191680; Mon 23-May-88 14:05:18 EDT
Date: Mon, 23 May 88 14:05 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: define-method-combination
To: kempf@Sun.COM
cc: Richarrd MLYnaRIk <Mly@AI.AI.MIT.EDU>, common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <8805231533.AA04572@suntana.sun.com>
Message-ID: <19880523180527.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 23 May 88 08:33:01 -0700
From: kempf@Sun.COM
More importantly for commercial purposes, C++. That's the competition.
While it is unlikely that we will be able to get performance comparible
to C++ on the first round, given your Sufficiently Smart compiler, it
should be possible to approach it. Whether a Sufficiently Smart CLOS
compiler happens, however, is again a question of priorities.
I agree with you, but would like to point out that I don't think the
existence of method combination has any bearing on the issue. I think
multiple inheritance and slot access are the areas that cause more
performance impact compared to C++. Furthermore I think the real
performance issues are entirely outside of CLOS, in areas such as
garbage collection and other things that Lisp does for you but C++
does not, and in the fact that the performance comparison is likely
to be on C's "home turf", hardware that is highly adapted for C and
less well adapted for Lisp.
∂23-May-88 1211 Common-Lisp-Object-System-mailer Define-Method-Combination
To: common-lisp-object-system@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I basically agree with Moon's replies to Richard's concerns.
On the topic of the added option to define-method-combination:
define-method-combination should accept an option
(:generic-function <symbol>) and bind <symbol> to the relevant
generic function.
I don't like the name ``:generic-function'' but I cannot think of a
better one. We're moving compute-applicable-methods and function-keywords
into chapter 2 today, so this wrinkle is minor.
-rpg-
∂23-May-88 1234 Common-Lisp-Object-System-mailer check-keyword-arguments
To: common-lisp-object-system@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
The two functions, compute-applicable-methods and function-arguments,
will appear in chapter 2. The inline code for make-instance will
appear in chapter 3.
-rpg-
∂23-May-88 1537 Common-Lisp-Object-System-mailer check-keyword-arguments
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 May 88 15:37:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 409032; Mon 23-May-88 18:37:03 EDT
Date: Mon, 23 May 88 18:36 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: check-keyword-arguments
To: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
cc: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: The message of 23 May 88 15:34 EDT from Dick Gabriel <RPG@SAIL.Stanford.EDU>
Message-ID: <19880523223659.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 23 May 88 1234 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
The two functions, compute-applicable-methods and function-arguments,
will appear in chapter 2. The inline code for make-instance will
appear in chapter 3.
Is the name function-arguments a typo?
∂23-May-88 1539 Common-Lisp-Object-System-mailer Comments on current state of Initialization.
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 23 May 88 15:37:56 PDT
Received: by labrea.stanford.edu; Mon, 23 May 88 15:37:54 PDT
Received: from bhopal.lucid.com by edsel id AA01958g; Mon, 23 May 88 15:29:01 PDT
Received: by bhopal id AA01677g; Mon, 23 May 88 15:32:51 PDT
Date: Mon, 23 May 88 15:32:51 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805232232.AA01677@bhopal.lucid.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: common-lisp-object-system@sail.stanford.edu
In-Reply-To: David A. Moon's message of Sat, 21 May 88 19:04 EDT <19880521230422.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Comments on current state of Initialization.
re: Date: Sat, 21 May 88 06:44:29 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Why should there still be three initialization protocls: "shared-
initialize", "initialize-instance", and "reinitialize-instance"?
[Summary: replace reinitialize-instance with a keyword argument to
initialize-instance --Moon]
Two reasons come immediately to mind: shared-initialize is also used when a
class is redefined or change-class is called; . . .
It seemed obvious to me that the "internal" callers from change-class etc.
could just as easily use a simpilifed definition of initialize-instance with
keyword argument.
-- JonL --
∂23-May-88 1600 Common-Lisp-Object-System-mailer check-keyword-arguments etc.
To: moon@STONY-BROOK.SCRC.SYMBOLICS.COM,
common-lisp-object-system@SAIL.Stanford.EDU
From: Linda DeMichiel <LGD@SAIL.Stanford.EDU>
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: check-keyword-arguments
Date: 23 May 88 1234 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
The two functions, compute-applicable-methods and function-arguments,
will appear in chapter 2. The inline code for make-instance will
appear in chapter 3.
Is the name function-arguments a typo?
Yes. It is called function-keywords in the draft that just went out
to the printers.
There are new chapter 2 files out on sail with these additions.
There is also a new macros file that should fix the [Primary Method]
formatting bug.
-lgd
∂23-May-88 1633 Common-Lisp-Object-System-mailer check-keyword-arguments
To: common-lisp-object-system@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
function-arguments is a typo for function-keywords. That's what I get
for talking on the phone while typing mail.
-rpg-
∂23-May-88 1649 Common-Lisp-Object-System-mailer Re: Mlynarik's comments
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 May 88 16:49:04 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 23 MAY 88 16:46:23 PDT
Date: Mon, 23 May 88 16:46 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Mlynarik's comments
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
cc: common-lisp-object-system@SAIL.Stanford.EDU
Fcc: BD:>Gregor>mail>outgoing-mail-2.text.newest
In-Reply-To: The message of 21 May 88 00:17 PDT from Dick Gabriel
<RPG@SAIL.Stanford.EDU>
Message-ID: <19880523234612.1.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no
Date: 21 May 88 00:17 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Richard writes:
``1-22 2nd PP in `Intro to methods': The first and second sentences
seem to be too directly contradictory. I would change the first to
``A method object is not NECESSARILY a function an IN GENERAL cannot be
invoked as a function.'' ''
The sentences in question are:
``A method object is not a function and cannot be invoked as a function. An
implementation may extend the \OS\ so that method objects are functions.''
The reason it is stated this way is that no one writing portable code can
take them to be functions, but we do not require them to not be functions
in all implementations.
Actually, the second sentence is wrong. We do prohibit them from being
functions in all implementations. Chapter 3 is very clear on this
issue. Methods are instances of the class standard-method which itself
is an instance of standard-class. We should delete the second sentence.
-------
∂23-May-88 1659 Common-Lisp-Object-System-mailer Chapter 1
To: common-lisp-object-system@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
The versions of Chapter 1 that are being sent to X3J13 are now
on [cls,lsp] on SAIL. You know what it is; you know what to do.
-rpg-
∂23-May-88 2332 Common-Lisp-Object-System-mailer Method Objects are not Functions
To: common-lisp-object-system@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I don't understand the reasoning that would argue that a method
object a priori cannot be a function.
-rpg-
∂24-May-88 1044 Common-Lisp-Object-System-mailer Re: Method Objects are not Functions
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 24 May 88 10:44:23 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 24 MAY 88 10:43:29 PDT
Date: Tue, 24 May 88 10:43 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Method Objects are not Functions
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
cc: common-lisp-object-system@SAIL.Stanford.EDU
Fcc: BD:>Gregor>mail>outgoing-mail-2.text.newest
In-Reply-To: The message of 23 May 88 23:32 PDT from Dick Gabriel
<RPG@SAIL.Stanford.EDU>
Message-ID: <19880524174313.4.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no
Date: 23 May 88 23:32 PDT
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I don't understand the reasoning that would argue that a method
object a priori cannot be a function.
The metaclass of a method object is standard-class. Standard-class does
not support the behavior which allows its metainstances to be
funcallable objects. Only funcallable-standard-class does that.
I suppose that some implementation could extend standard-class to do
that, but I don't see that as a freedom we really need to allow.
-------
∂24-May-88 1105 Common-Lisp-Object-System-mailer Callable Methods
To: common-lisp-object-system@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I am aware of the proposed ontology of method objects, but I think we need
to carefully think about how much of the hierarchy to uniquely specify in
Ch3. That is, method objects are things that on the surface could be
callable. Therefore, maybe the metaclass should be something distinct from
from standard-class, but with the proviso that it is acceptable to either
identify this metaclass with standard-class or to hang it under
funcallable-standard-class.
-rpg-
∂26-May-88 1055 Common-Lisp-Object-System-mailer with-added-methods
Received: from XX.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 May 88 10:54:57 PDT
Received: from PERON.AI.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 26 May 88 13:55-EDT
Date: Thu, 26 May 88 13:58 EDT
From: Richard Mlynarik <MLY@AI.AI.MIT.EDU>
Subject: with-added-methods
To: common-lisp-object-system@SAIL.STANFORD.EDU
Message-ID: <19880526175838.6.MLY@PERON.AI.MIT.EDU>
[Apologies if I am rehashing an issue which has been previously discussed
-- the local CLOS archives are presently inaccessible.]
with-added-methods seems incompatible with the restriction (mentioned in
the doc for add-method) that a method can only be added to one generic
function at a time.
The doc for with-added-methods says:
Each generic function is created by adding the set of methods
specified by its method definitions to a copy of the lexically visible
generic function of the same name and its methods.
That for add-method says:
If the method object is a method object of another generic function,
an error is signaled.
I would think that the new generic function created by
with-added-methods must share all all the methods which were defined on
the original generic function.
I suppose that an alternate reading of the first piece of documentation
is ``to a copy of the lexically visible generic function of the same
name and TO A COPY OF its methods'' -- I'd like to think that this isn't
what was intended, since it would seem to introduce far more problems
than it solves.
Some passing remarks about with-added-methods:
* Does it really need to be a special form rather than a macro?
I -believe- I could define it in terms of generic-flet -- however,'
I haven't thought this through very thoroughly.
* Is there sufficient Chapter 3 support to enable this kind of thing to
be `portably' implemented? Apart from the above-mentioned lossage
involving methods added to more than one generic function, there are
problems brushed under the rug by ``A COPY OF the lexically
visible generic function.'' Presumably there needs to be some
cloning method for generic functions.
* I guess I'll never actually use with-added-methods in any case
because of inefficiencies due what I perceive as the fatal problem
with method-combination...
∂02-Jun-88 1329 Common-Lisp-Object-System-mailer [David N Gray <Gray@DSG>: making structures]
Received: from ti.com by SAIL.Stanford.EDU with TCP; 2 Jun 88 13:29:15 PDT
Received: by ti.com id AA14212; Thu, 2 Jun 88 15:28:26 CDT
Received: from Jenner by tilde id AA23256; Thu, 2 Jun 88 15:26:36 CDT
Message-Id: <2790274788-645613@Jenner>
Date: Thu, 2 Jun 88 15:19:48 CDT
From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
To: Common-lisp-object-system@sail.stanford.edu
Subject: [David N Gray <Gray@DSG>: making structures]
I thought I'd pass this along. There is no need to include Gray in the
reply since he is out of town for two month.
------- Forwarded Message
Patrick,
The May 23 draft of the CLOS spec still has the following text on page
1-15: "Calling MAKE-INSTANCE to create an instance of STRUCTURE-CLASS
signals an error." This still seems like an undesirable and unnecessary
limitation to me.
-- David Gray
------- End of Forwarded Message
∂20-Jun-88 1330 Common-Lisp-Object-System-mailer Compile-file environment
Received: from ti.com by SAIL.Stanford.EDU with TCP; 20 Jun 88 13:30:19 PDT
Received: by ti.com id AA24079; Mon, 20 Jun 88 15:27:31 CDT
Received: from Jenner by tilde id AA06995; Mon, 20 Jun 88 15:17:37 CDT
Message-Id: <2791829681-8355429@Jenner>
Date: Mon, 20 Jun 88 15:14:41 CDT
From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
To: common-lisp-object-system@SAIL.STANFORD.EDU
Subject: Compile-file environment
In order to compile in advance (compile-file time ) some implementation
aspects of CLOS metaobjects, there must be some clos metaobjects
residing in an implementation dependent environment, that do not visibly
side effect the runtime environment. The visible entry points to this
environment come from name to object mapping (FIND-CLASS and
ENSURE-GENERIC-FUNCTION). I propose that a runtime environment CLOS
object cannot visibly point to a compile-file environment object(No
visible cross environment links). I think that makes metaclass
programming a lot easier.
Environment Capture
When compiling CLOS DEF.. forms, a evaluation must take place that
affects the compile-file environment, and this evaluation must be a
similar to what happens when the forms are evaluated.
I propose that the standard expansion of the DEF... macro be:
(defclass foo () ())
=>
(eval-when (load eval compile)
(add-named-class (class-prototype (find-class "STANDARD-CLASS"
(name-environment env)))
:name 'foo
:environment (name-environment env)))
Where name-environment take the value of a macroexpand environment and
returns the right environment for the right situation. The value
returned by name-environment can be passed as the environment argument
to all CLOS functions that accept and environment argument.
Presumably, when evaluated in the EVAL and COMPILE-TO-CORE situation,
this name-environment returns NIL (the runtime environment). When
evaluated in the COMPILE-FILE environment, it returns the compile-file
environment. When evaluated in LOAD situation, it returns the runtime
environment. Since the compiler and the evaluator have to treat this
function differently, Logically, this is a special form.
Environments behavior
The compiler should be responsible for implementing the inheritance and
shadowing of objects in different environments. However, find-class
should not return a runtime object when the environment argument points
to a compile-file environment. This avoids cross references across
environments. I don't think this is a good idea for FIND-CLASS to
return a created class object when an inheritance has to happen. I
think that should be explicitly done by calling MAKE-DEFAULT-METAOBJECT.
MAKE-DEFAULT-METAOBJECT metaobject-prototype name &optional environment. Generic-function
The default method on standard-class returns
a forwarded-class when the environment is a runtime environment, and
does the implementation dependent environment inheritance or
forwarded-class creation if the environment is a compile-file
environment.
Inside of ADD-NAMED-CLASS, MAKE-DEFAULT-METAOBJECT is called when (find-class
class-name nil environment) returns NIL.
Inside of ADD-NAMED-METHOD (or something like that), during the
normalization of the specializers,MAKE-DEFAULT-METAOBJECT needs to be
called if (find-class class-name nil environment) returns NIL when the
environment is a compile-file environment.
Inside of ENSURE-GENERIC-FUNCTION, we need to have the same mechanism.
Either we extend FBOUNDP to accept an environment argument, or we come
up with an equivalent of FIND-CLASS, does not matter much.
MAKE-DEFAULT-METAOBJECT is specialized on standard-generic-function and
returns the appropriate generic function object.
Patrick.
∂22-Jun-88 1448 Common-Lisp-Object-System-mailer SYMBOL-MACROLET-UTILITY
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 22 Jun 88 14:46:14 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA21530; Wed, 22 Jun 88 14:46:01 PDT
Message-Id: <8806222146.AA21530@decwrl.dec.com>
From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
Date: 22 Jun 88 17:38
To: Common-Lisp-Object-System@sail.stanford.edu
Subject: SYMBOL-MACROLET-UTILITY
I'm getting to ready to submit this as a cleanup proposal; I thought I'd run
it by here first. My intent in submitting the proposal for cleanup is to open
the discussion of whether SYMBOL-MACROLET is really a desirable language
feature. If it is resolved that SYMBOL-MACROLET is worth keeping, I have a
follow-up proposal to at least make it a special form.
/JEP
===============================================================================
Status: DRAFT
Issue: SYMBOL-MACROLET-UTILITY
References: X3J13 document 88-002R, Chapter 2, pp. 2-81f., 2-88f., 2-92f.
Category: DELETION
Edit history: 21-Jun-88, Version 1 by Piazza
Problem Description:
Anything expressible with SYMBOL-MACROLET could also be written with
regular MACROLET, except that the macro symbol could not stand alone as an
expression; it would have to be enclosed in parentheses. The cost
associated with implementing and maintaining the SYMBOL-MACROLET feature
exceeds this incremental utility.
Proposal (SYMBOL-MACROLET:FLUSH):
Remove SYMBOL-MACROLET (and WITH-ACCESSORS and WITH-SLOTS) from 88-002R.
Rationale:
Flushing SYMBOL-MACROLET eliminates the cost of implementing and
maintaining this feature, while MACROLET still provides most of
SYMBOL-MACROLET's expressive power.
------------------------------------------------------------------------------
Current Practice:
Portable Common Loops provides a code-walking implementation of
SYMBOL-MACROLET as specified in 88-002R.
Cost to Implementors:
Presumably few implementors have implemented SYMBOL-MACROLET, excepting
the implementation provided by PCL. If it is flushed from the language,
no one will incur any implementation cost.
Cost to Users:
Users will lose the expressive ability provided by SYMBOL-MACROLET,
WITH-ACCESSORS, and WITH-SLOTS, and will have to make do with MACROLET.
Cost of Non-Adoption:
Implementors must implement significant new functionality, adding to
system size and language complexity. (A separate proposal,
SYMBOL-MACROLET-SEMANTICS, addresses problems with the currently
specified semantics of SYMBOL-MACROLET.)
Benefits:
SYMBOL-MACROLET:FLUSH reduces the implementation and maintenance costs for
a Common Lisp implementation. It also simplifies the language by
eliminating the concept of a "symbol macro."
Aesthetics:
There seem to be mixed feelings as to the desirability of SYMBOL-MACROLET
as a construct in the language. Some feel it hairs up the language while
offering only trivial benefit beyond what is already provided through
normal macros. Others herald it as a important new language feature.
Discussion:
As it was adopted by X3J13 as part of CLOS, there has been no formal
discussion on the pros and cons SYMBOL-MACROLET on its own.
∂24-Jun-88 1225 Common-Lisp-Object-System-mailer which functions should be generic?
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 24 Jun 88 12:25:16 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 24 JUN 88 12:20:08 PDT
Date: 24 Jun 88 12:19 PDT
From: Masinter.pa@Xerox.COM
Subject: which functions should be generic?
To: common-lisp-object-system@sail.stanford.edu
Message-ID: <880624-122008-5902@Xerox>
Mr. Ida asks (relative to COERCE-INCOMPLETE):
"Will Coerce function be a (standard) generic function ?"
I'd like to generalize this: Now that CLOS is part of the standard, which
functions in CL should be generic?
∂24-Jun-88 1332 Common-Lisp-Object-System-mailer Re: which functions should be generic?
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 24 Jun 88 13:31:53 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
id AA28747; Fri, 24 Jun 88 13:30:10 PDT
Received: from suntana.sun.com by snail.sun.com (4.0/SMI-3.2)
id AA18466; Fri, 24 Jun 88 13:26:07 PDT
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
id AA07800; Fri, 24 Jun 88 13:30:29 PDT
Message-Id: <8806242030.AA07800@suntana.sun.com>
To: Masinter.pa@Xerox.COM
Cc: common-lisp-object-system@sail.stanford.edu
Subject: Re: which functions should be generic?
In-Reply-To: Your message of 24 Jun 88 12:19:00 -0700.
<880624-122008-5902@Xerox>
Date: Fri, 24 Jun 88 13:30:26 -0700
From: kempf@Sun.COM
1) All the sequence functions (Chapter 14)
2) Stream functions and output functions which use streams
(Chapters 21 & 22). Even though, or perhaps because, extensible
streams are not yet part of the CLOS draft, generic output
functions would be useful.
jak
∂24-Jun-88 1545 Common-Lisp-Object-System-mailer which functions should be generic?
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 24 Jun 88 15:44:57 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 424437; Fri 24-Jun-88 18:44:06 EDT
Date: Fri, 24 Jun 88 18:43 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: which functions should be generic?
To: Masinter.pa@Xerox.COM
cc: common-lisp-object-system@sail.stanford.edu
In-Reply-To: <880624-122008-5902@Xerox>
Message-ID: <19880624224355.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 24 Jun 88 12:19 PDT
From: Masinter.pa@Xerox.COM
Mr. Ida asks (relative to COERCE-INCOMPLETE):
"Will Coerce function be a (standard) generic function ?"
It's difficult to implement COERCE's dispatch in terms of generic
function dispatch since equivalence of type specifiers is not done
in an object-oriented way. There is no way to write a method that
is applicable both for (coerce '(#\a) 'string) and for
(coerce '(#\a) '(vector string-char)), even though both of those
forms mean the same thing.
I'd like to generalize this: Now that CLOS is part of the standard, which
functions in CL should be generic?
I think this is the wrong mailing list to discuss changes that X3J13, or
anyone else, might want to make to the language in order to take advantage
of CLOS.
∂24-Jun-88 1648 Common-Lisp-Object-System-mailer Re: which functions should be generic?
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Jun 88 16:48:51 PDT
Received: from hplabs.HP.COM by SCORE.STANFORD.EDU with TCP; Fri 24 Jun 88 16:50:28-PDT
Received: from hplms2.HP.COM (hplms2) by hplabs.HP.COM with SMTP ; Fri, 24 Jun 88 15:39:09 PST
Received: from hplwhh.HPL.HP.COM (hplwhh.hpl.hp.com) by hplms2.HP.COM; Fri, 24 Jun 88 16:38:46 pdt
Received: from hplwhh by hplwhh.HPL.HP.COM; Fri, 24 Jun 88 16:37:05 pdt
To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: common-lisp-object-system@sail.stanford.edu
Subject: Re: which functions should be generic?
X-Mailer: mh6.5
In-Reply-To: Your message of Fri, 24 Jun 88 18:43:00 -0400.
<19880624224355.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 24 Jun 88 16:37:03 PDT
Message-Id: <6353.583198623@hplwhh>
From: Warren Harris <harris%hplwhh@hplabs.HP.COM>
> It's difficult to implement COERCE's dispatch in terms of generic
> function dispatch since equivalence of type specifiers is not done
> in an object-oriented way.
This could be handled in the same way as the PRINT-OBJECT generic function.
Implementations are required to call it from within their print system.
One could supply a COERCE-OBJECT generic function which the COERCE function
would ultimately call if the coercion argument named a class.
I realize that one could probably find a large number of candidates in CLtL
to be made generic. Ideally EQUAL should be generic too. It already
depends on the type of objects you give it, looking inside of vectors, etc.
Why not allow it to look inside of objects in an object dependent way?
At some point the argument boils down to an efficiency consideration. I
don't think anyone would be happy if EQ was required to be generic. There
should be a strong rational for which functions are to be made generic and
which are not. (For example: how should the average user know when to use
ELT instead of SVREF?) Perhaps a generic layer of CL is in order. CL
already kind of does this with its sequence operations. I can think of three
generic protocols off hand:
- sequences which access subcomponents by position
- objects and structures which access subcomponents by name
- math functions which operate on generic "numbers"
It would be nice if CL had facilities for formally specifying the protocols
for abstract classes like NUMBER, SEQUENCE, or OBJECT (i.e. first class
protocol objects, or an abstract-class metaclass), and allow individual
classes to implement a protocol. This way the user can write code that
meets a protocol without regard to the specifics of its implementation.
∂25-Jun-88 1204 Common-Lisp-Object-System-mailer Re: which functions should be generic?
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 25 Jun 88 12:04:03 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 424648; Sat 25-Jun-88 15:01:44 EDT
Date: Sat, 25 Jun 88 15:01 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: which functions should be generic?
To: Warren Harris <harris%hplwhh@hplabs.HP.COM>
cc: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <6353.583198623@hplwhh>
Message-ID: <19880625190143.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 24 Jun 88 16:37:03 PDT
From: Warren Harris <harris%hplwhh@hplabs.HP.COM>
> It's difficult to implement COERCE's dispatch in terms of generic
> function dispatch since equivalence of type specifiers is not done
> in an object-oriented way.
This could be handled in the same way as the PRINT-OBJECT generic function.
Implementations are required to call it from within their print system.
One could supply a COERCE-OBJECT generic function which the COERCE function
would ultimately call if the coercion argument named a class.
But it's meaningful for COERCE's second argument to be a type specifier that
does not name a class. CLtL gives as an example (vector (complex short-float)).
It would be inconsistent to do some coercions with classes and others through
some other mechanism. I don't think your idea will work without a larger
recasting of Common Lisp in object-oriented terms. While that's an interesting
project for investigation, I suspect it would quickly go way beyond the
proper charter of a standardization effort.
It would be nice if CL had facilities for formally specifying the protocols
for abstract classes like NUMBER, SEQUENCE, or OBJECT (i.e. first class
protocol objects, or an abstract-class metaclass), and allow individual
classes to implement a protocol. This way the user can write code that
meets a protocol without regard to the specifics of its implementation.
While I strongly agree with this, and have thought so for several years, again
I feel this is beyond the proper charter of a standardization effort. There
does not appear to be any current practice at all, let alone a concensus from
which to build a standard.
Some of the directions in which I feel Lisp ought to evolve in the 1990s
include enormously better tools for modularity and program packaging,
like what such languages as Ada have but better conceived and (as always
in Lisp) more flexible (the "locales" found in some dialects in Scheme
might be a good place to start); formal notions of protocols and
machine-understandable interface specifications; complete integration of
database concepts into the language; and development tools that
"understand" both Lisp programming concepts and the dynamics of large
development teams. None of this is X3J13's business, which is to
stabilize the Lisp of the 1980s so people can use it.
∂03-Jul-88 1051 RPG The Law of Demeter
∂28-Jun-88 2050 Owners-commonloops.pa@xerox.com The Law of Demeter
Received: from parcvax (PARCVAX.XEROX.COM) by SAIL.Stanford.EDU with TCP; 28 Jun 88 20:50:43 PDT
Received: by parcvax (5.54/1.15)
id AA11667; Tue, 28 Jun 88 20:11:04 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 28 JUN 88 20:07:53 PDT
Return-Path: <RPG@SAIL.Stanford.EDU>
Redistributed: commonloops.pa
Received: from SAIL.Stanford.EDU ([10.0.0.11]) by Xerox.COM ; 28 JUN 88 20:06:52
PDT
Message-Id: <uqAwE@SAIL.Stanford.EDU>
Date: 28 Jun 88 20:06 PDT
From: Dick Gabriel <RPG@sail.stanford.edu>
Subject: The Law of Demeter
To: commonloops.pa@xerox.com
I just wrote a poem that helps explain the Law of Demeter (apologies
to Wallace Stevens):
Thirteen Ways of Looking at the Law of Demeter
I
Among twenty snowy mountains,
The only moving thing
Was the Speaker of the Law.
II
I was of three minds,
Like a program
In which there are three violations.
III
The Sheet of the Law whirled in the autumn winds.
It was a small part of the pantomime.
IV
A message and an argument
Are one.
A message and an argument and the Law
Are one.
V
I do not know which to prefer,
The beauty of inflections
Or the beauty of innuendos,
The Law speaking
Or just after.
VI
Icicles filled the long window
With barbaric glass.
The shadow of the Speaker
Crossed it to and fro.
The mood
Traced in the shadow
An indecipherable cause.
VII
O thin men of Haddam,
Why do you imagine golden birds?
Do you not see how the Law
Walks around the feet
Of the programs about you?
VIII
I know noble accents
And lucid, inescapable rhythms;
But I know, too,
That the Law is involved
In what I know.
IX
When the Law disappeared from sight,
It marked the edge
Of one of many circles.
X
At the sight of the Law
Working in green light,
Even the bawds of euphony
Would cry out sharply.
XI
He rode over Connecticut
In a glass coach.
Once, a fear pierced him,
In that he mistook
The shadow of his equipage
For a violation.
XII
The river is moving.
The Law must be working.
XIII
It was evening all afternoon.
It was snowing.
And it was going to snow.
The Law sat
On a sheet of paper.
∂11-Jul-88 1111 CL-Object-Oriented-Programming-mailer CLOS Workshop
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jul 88 11:11:23 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUL 88 11:06:55 PDT
Date: Mon, 11 Jul 88 11:02 PDT
From: Gregor.pa@Xerox.COM
Reply-To: Gregor@GRAPEVINE.parc.xerox.com
Subject: CLOS Workshop
To: Common-Lisp@Sail.Stanford.edu, common-lisp-object-system@sail.stanford.edu,
CL-Object-Oriented-Programming@Sail.Stanford.edu, CommonLoops.pa@Xerox.COM
Fcc: BD:>Gregor>mail>outgoing-mail-2.text.newest
Message-ID: <19880711180221.8.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no
Workshop for CLOS Users and Implementors
October 3rd and 4th
Xerox PARC
Palo Alto, California
We have been excited by the extent to which CLOS is already being
used, and the ways in which it is being extended. The purpose of
this workshop is to provide an opportunity for the members of the
CLOS community to get together and share their experience.
To provide a good start for the interchange, we are requesting that
participants supply a short position paper (1-3 pages) describing
work related to CLOS. Some topics of interest are:
Applications
Programming Techniques
Implementation
Programming Environment Tools
Extensions of CLOS
Techniques for Converting to CLOS
Meta Object Techniques and Theory
Critiques
We will try to support demonstrations or videotapes of applications,
programming environments, implementations or other relevant systems.
If you are planning to attend, please let us know by August 15th.
This will help us with planning and allow us to arrange a discount
rate at a local hotel.
Position papers should reach us by September 9th so that we can
organize a program and arrange for duplication of the papers.
Position papers, notice to attend, and other correspondence should
be sent to:
Gregor Kiczales
3333 Coyote Hill Rd.
Palo Alto, CA 94304
or by Internet mail to:
Gregor.pa@Xerox.com
-------
∂15-Jul-88 1304 Common-Lisp-Object-System-mailer putting CLOS objects in binfiles
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 15 Jul 88 13:04:09 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
id AA27189; Fri, 15 Jul 88 13:02:05 PDT
Received: from lukasiewicz.sun.com by snail.sun.com (4.0/SMI-3.2)
id AA05872; Fri, 15 Jul 88 13:02:42 PDT
Received: by lukasiewicz.sun.com (4.0/SMI-4.0)
id AA07423; Fri, 15 Jul 88 12:42:03 PDT
Date: Fri, 15 Jul 88 12:42:03 PDT
From: jrose@Sun.COM (John Rose)
Message-Id: <8807151942.AA07423@lukasiewicz.sun.com>
To: common-lisp-object-system@sail.stanford.edu
Subject: putting CLOS objects in binfiles
It's a shame that there's no provision in CLOS for
saving objects in binfiles. It's going to blow up
in our faces when CLOS gets ubiquitous enough for
people to use CLOS objects without being aware of it.
(I.e., when lower layers of layered products use
CLOS without advertising the fact.)
The reason is that the default object fasdumper
does a GC-style walk over the object, dumping not
only the object but also its class hierarchy.
Saving one object got me a binary file of over 100Kb.
(In Lucid 3.0.)
People expect to use binary files to store data in!
If CLOS objects can't be dumped, it will effectively
mean that you can't store data in Common Lisp binary files.
It's like that ancient MIT story about Lisp packages:
The first time they tried to fasdump a package object,
much of the Lisp world went along with it. This kind
of behavior has to be fixed in real systems. (As
with our future unaware user of CLOS, the MIT package
fasdump meltdown happened unexpectedly. A bare "FOO:"
used to mean the FOO package object, instead of its present
meaning.)
Can a fix for this get sneaked into Chapter 3 of
the CLOS spec?
Here's essentially what's needed: A generic function
(called, say, RECONSTRUCTOR-FORM) which returns a
Lisp form to evaluate to reconstruct any given
object. It can return NIL, which means to do
some system default, like a GC-style walk.
The reconstructor form would be stored in
lieu of the real object into the binary file,
adorned with #, for evaluation at load time.
A different way to factor things would be to
have a function RECONSTRUCTOR-INITS which
computes at dump time a class name and keyword/value
plist, and a function RECONSTRUCT-INSTANCE analogous
to and equivalent by default to MAKE-INSTANCE,
which is called at load time on the saved data.
The fasdumper (and other utilities, like an object
migrator) could use protocols like these to handle
user-defined types correctly.
Using #, is not a solution: A fasdumper needs to
correctly handle CLOS objects wherever they occur
in the data structures being dumped.
Here's my immediate problem: I want to build objects
which represent predicates in a special purpose query
language, and I want them to be uniquified, like pathnames
on the Lisp Machine. (They cache things like compiled Lisp
code, so it's expensive to build new copies.) Such things
do not dump properly, and even if a simple patch were to
be applied (say, to dump a class symbol instead of a class),
a simple-minded load routine would not uniquify them.
-- John
∂15-Jul-88 1408 Common-Lisp-Object-System-mailer putting CLOS objects in binfiles
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Jul 88 14:08:45 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 434003; Fri 15-Jul-88 17:07:46 EDT
Date: Fri, 15 Jul 88 17:07 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: putting CLOS objects in binfiles
To: John Rose <jrose@Sun.COM>
cc: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <8807151942.AA07423@lukasiewicz.sun.com>
Message-ID: <19880715210732.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 15 Jul 88 12:42:03 PDT
From: jrose@Sun.COM (John Rose)
It's a shame that there's no provision in CLOS for
saving objects in binfiles.
CLOS doesn't address this because Common Lisp doesn't.
Note that CL provides no way to write a "binfile" other than
COMPILE-FILE. Of course you can trick COMPILE-FILE into
doing anything, using macros, so that's no real limitation.
The reason is that the default object fasdumper
does a GC-style walk over the object, dumping not
only the object but also its class hierarchy.
That's a statement about some particular implementation,
not about Common Lisp.
Can a fix for this get sneaked into Chapter 3 of
the CLOS spec?
Chapter 3 would be the wrong place. This is logically
a Chapter 2 facility, in the same vein as PRINT-OBJECT.
The status of CLOS is that it has been accepted by X3J13
into the same status as CLtL. This means that it is open to
cleaning up and improvement through the normal X3J13
mechanisms, and I think your suggestion makes a great deal
of sense and should be done through those mechanisms. Do
you want to make the proposal (I don't know if you're
familiar with X3J13), or do want to ask someone on the
CLOS committee to do it?
Here's essentially what's needed: A generic function
(called, say, RECONSTRUCTOR-FORM) which returns a
Lisp form to evaluate to reconstruct any given
object.
This is fine. It's how Flavors does it, so there is some
precedent. The only problem with this technique is that it
doesn't cope well with circular structures, which can only
be handled by separating creation of the objects from filling
them in (and even that doesn't work in general, for reasons
too complicated to get into here).
It can return NIL, which means to do
some system default, like a GC-style walk.
I think this is a really bad idea. My experience is that there is no
default that is right for all objects and any attempt to offer a default
does users more harm than good, because the default gets used for cases
where it can't work any causes hard to understand problems.
Furthermore, if there was a default, it should be implemented by a
default method for the generic function, not by special-casing NIL. I'd
prefer that there be no default and hence if the user has not defined a
method, an error is signalled.
Here's my immediate problem: I want to build objects
which represent predicates in a special purpose query
language, and I want them to be uniquified, like pathnames
on the Lisp Machine. (They cache things like compiled Lisp
code, so it's expensive to build new copies.) Such things
do not dump properly, and even if a simple patch were to
be applied (say, to dump a class symbol instead of a class),
a simple-minded load routine would not uniquify them.
I'm not sure that anything in Common Lisp requires that multiple
references to a single object, in a file being compiled, do not
turn into multiple objects when the file is loaded. You might have
to address this in an implementation-dependent way unless the
definition of Common Lisp were changed to require this explicitly.
I think most implementations do guarantee object identity within
a single COMPILE-FILE, even though they're not required to.
This is not a CLOS issue, it applies to all objects for which EQ
is defined.
∂15-Jul-88 1719 Common-Lisp-Object-System-mailer Re: putting CLOS objects in binfiles
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Jul 88 17:19:05 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 JUL 88 17:08:30 PDT
Date: 15 Jul 88 17:08 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: putting CLOS objects in binfiles
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Fri, 15 Jul 88 17:07 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: jrose@Sun.COM, common-lisp-object-system@SAIL.STANFORD.EDU
Message-ID: <880715-170830-1592@Xerox>
Here's my immediate problem: I want to build objects
which represent predicates in a special purpose query
language, and I want them to be uniquified, like pathnames
on the Lisp Machine. (They cache things like compiled Lisp
code, so it's expensive to build new copies.) Such things
do not dump properly, and even if a simple patch were to
be applied (say, to dump a class symbol instead of a class),
a simple-minded load routine would not uniquify them.
"I'm not sure that anything in Common Lisp requires that multiple
references to a single object, in a file being compiled, do not
turn into multiple objects when the file is loaded. You might have
to address this in an implementation-dependent way unless the
definition of Common Lisp were changed to require this explicitly."
In Loops, the way we solved this problem was to provide each savable object a
unique identifier. This UID was constructed from some representation of the
machine of ceation and the time of creation. An object knows its UID, and from
the UID one can find the object. For any object, the form that was dumped
includes its UID, as well as its contents. References from a dumped object to
another object contain a form which reconstructs the pointer to object referred
to, but does not try to reconstruct its contents.
Suppose we had an objects O1 and O2, of classes FOO and FIE respectively, each
with one slot named OTHER pointing to the other object. Then dumping them to a
file might create expressions like:
#,(reconstruct-object uid1 FOO OTHER #.(pointer-to-object uid2 FIE))
#,(reconstruct-object uid2 FOO OTHER #.(pointer-to-object uid1 FOO))
The result of evaluating (pointer-to-object uid2 FIE) is to create an
uninitialized object of class FIE, and make it be the value of the slot OTHER of
O1. O1 is the object created by the first reconstruct-object form, with UID
uid1. Evaluating the second reconstruct-object form changes the contents of the
uninititialized object. Evaluating the form (pointer-to-object uid1 FOO) finds
the first object created.
As far as tracing through objects, we found it was better to separate out the
process of finding all objects that you want dumped (a user defined trace that
creates a list). One then dumps each of the listed objects. Stan Lanning
implemented a preliminary CLOS version that we have been experimenting with.
∂18-Jul-88 0808 Common-Lisp-Object-System-mailer Re: putting CLOS objects in binfiles
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 18 Jul 88 08:08:54 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
id AA22842; Mon, 18 Jul 88 08:06:28 PDT
Received: from suntana.sun.com by snail.sun.com (4.0/SMI-4.0)
id AA15584; Mon, 18 Jul 88 08:07:04 PDT
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
id AA18158; Mon, 18 Jul 88 08:06:20 PDT
Message-Id: <8807181506.AA18158@suntana.sun.com>
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: John Rose <jrose@Sun.COM>, common-lisp-object-system@SAIL.STANFORD.EDU
Subject: Re: putting CLOS objects in binfiles
In-Reply-To: Your message of Fri, 15 Jul 88 17:07:00 -0400.
<19880715210732.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 18 Jul 88 08:06:17 -0700
From: kempf@Sun.COM
>I'm not sure that anything in Common Lisp requires that multiple
>references to a single object, in a file being compiled, do not
>turn into multiple objects when the file is loaded. You might have
Yes, in fact, there is one Common Lisp implementation in which references
to vectors are not EQ after loading. After looking through selected sections
of CLtL, no guarantees seem to be made about preserving EQness between compile
time and run time.
jak
∂18-Jul-88 1307 Common-Lisp-Object-System-mailer putting CLOS objects in binfiles
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 18 Jul 88 13:07:13 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
id AA29734; Mon, 18 Jul 88 13:04:21 PDT
Received: from lukasiewicz.sun.com by snail.sun.com (4.0/SMI-4.0)
id AA29199; Mon, 18 Jul 88 13:04:51 PDT
Received: by lukasiewicz.sun.com (4.0/SMI-4.0)
id AA18995; Mon, 18 Jul 88 13:06:16 PDT
Date: Mon, 18 Jul 88 13:06:16 PDT
From: jrose@Sun.COM (John Rose)
Message-Id: <8807182006.AA18995@lukasiewicz.sun.com>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, Bobrow.pa@Xerox.COM
Cc: common-lisp-object-system@SAIL.STANFORD.EDU
Cc: jrose@Sun.COM
In-Reply-To: David A. Moon's message of Fri, 15 Jul 88 17:07 EDT <19880715210732.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: putting CLOS objects in binfiles
Date: Fri, 15 Jul 88 17:07 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: Fri, 15 Jul 88 12:42:03 PDT
From: jrose@Sun.COM (John Rose)
It's a shame that there's no provision in CLOS for
saving objects in binfiles.
...
Here's essentially what's needed: A generic function
(called, say, RECONSTRUCTOR-FORM) which returns a
Lisp form to evaluate to reconstruct any given
object.
This is fine. It's how Flavors does it, so there is some
precedent. The only problem with this technique is that it
doesn't cope well with circular structures, which can only
be handled by separating creation of the objects from filling
them in (and even that doesn't work in general, for reasons
too complicated to get into here).
...
OK, I'd like to create a proposal. I understand my hallmate
Cris Perdue is thinking about binfiles, so I'll talk with him
some first.
To deal with circularities, one can separate the object creation
protocol into two passes, one to create a reference to an uninitialized
object (which can be used to plug into other structures), and a second
pass to initialize the object itself. You say there are in
general problems here, and I imagine you are referring to
the window between the two passes, when the object can be
referenced, but might not yet contain valid data. Do you
think this problem can be addressed adequately as follows:
At dump time, if circularities are detected, the target
of a back-arc (which will need to be created in two passes
at load time) is passed to a generic function (named, e.g.,
CIRCULAR-RECONSTRUCTOR-FORMS) which either generates parameters
for the two load time passes, or signals an error at dump time.
This would allow a class to disallow all or some circularities,
or handle them in a class-specific manner, by gaining some control
over the window between the two load time passes. An object
in the inter-pass window could even have a different class; pass 2
could perform a CHANGE-CLASS.
Also, let me make another stab at a default behavior for dumping:
Use the PRINT-OBJECT printer, and save the string the binary file.
Proper use of a *PRINT-READABLY* flag would be required to detect errors,
and recursive calls to PRINT-OBJECT would have to transfer
control to the binary dumper (leaving a #<n># or similar
notation in the object's string). The advantage of this
default is that the class writer need only code a readable
PRINT-OBJECT representation, and not worry about binary files
explicitly.
Here's my immediate problem: I want to build objects
which represent predicates in a special purpose query
language, and I want them to be uniquified, like pathnames
on the Lisp Machine. (They cache things like compiled Lisp
code, so it's expensive to build new copies.) Such things
do not dump properly, and even if a simple patch were to
be applied (say, to dump a class symbol instead of a class),
a simple-minded load routine would not uniquify them.
I'm not sure that anything in Common Lisp requires that multiple
references to a single object, in a file being compiled, do not
turn into multiple objects when the file is loaded.
Symbols load as single objects. And on the Lisp Machine (last
time I looked) pathnames were interned in the same way.
I think this is done because symbols and pathnames are
used as names, or references for other objects, and making
them EQ makes for fast comparison, and allows referencing
parties to make shared annotations on the name object.
You might have
to address this in an implementation-dependent way unless the
definition of Common Lisp were changed to require this explicitly.
I think most implementations do guarantee object identity within
a single COMPILE-FILE, even though they're not required to.
This is not a CLOS issue, it applies to all objects for which EQ
is defined.
I'm willing to guarantee object identity myself, if I can only
get control whenever the system thinks it wants to cons one of
my objects, and intern it. Something like this:
(LET ((TABLE (MAKE-HASH-TABLE :TEST 'EQUAL)))
(DEFMETHOD MAKE-INSTANCE ((EQL 'MYCLASS) &KEY X Y)
(LET ((PARAMS (LIST X Y)))
(OR (GETHASH PARAMS TABLE)
(SETF (GETHASH PARAMS TABLE)
(CALL-NEXT-METHOD))))))
Date: 15 Jul 88 17:08 PDT
From: Bobrow.pa@Xerox.COM
In Loops, the way we solved this problem was to provide each savable object a
unique identifier. This UID was constructed from some representation of the
machine of ceation and the time of creation. An object knows its UID, and from
the UID one can find the object. For any object, the form that was dumped
includes its UID, as well as its contents. References from a dumped object to
another object contain a form which reconstructs the pointer to object referred
to, but does not try to reconstruct its contents.
Wow! That's neat stuff. It shows how far we've come that solutions
to the problem of object identity within a single Lisp session are taken
for granted (reread the CLtL chapter on packages if you think it's
no problem) and the current research is into defining and maintaining
uniqueness across much wider domains, such as all machines and times
in some space.
But all I wanted (this time) was uniqueness across a session, and
some sort of transportable printed representation, like symbols or LispM
pathnames.
-- John